summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
diff options
context:
space:
mode:
authorJiri Benc <jbenc@redhat.com>2013-08-01 08:41:28 (GMT)
committerDavid S. Miller <davem@davemloft.net>2013-08-01 21:16:20 (GMT)
commit8a226b2cfa776db6011fc84b71578513161cd3d3 (patch)
tree7d9cc6e14f0e99e576f761f82c1d350378ef44e8 /drivers/net/ethernet
parent3f8f52982ad020f0704548c46de66bf464d3b967 (diff)
downloadlinux-fsl-qoriq-8a226b2cfa776db6011fc84b71578513161cd3d3.tar.xz
ipv6: prevent race between address creation and removal
There's a race in IPv6 automatic addess assignment. The address is created with zero lifetime when it's added to various address lists. Before it gets assigned the correct lifetime, there's a window where a new address may be configured. This causes the semi-initiated address to be deleted in addrconf_verify. This was discovered as a reference leak caused by concurrent run of __ipv6_ifa_notify for both RTM_NEWADDR and RTM_DELADDR with the same address. Fix this by setting the lifetime before the address is added to inet6_addr_lst. A few notes: 1. In addrconf_prefix_rcv, by setting update_lft to zero, the if (update_lft) { ... } condition is no longer executed for newly created addresses. This is okay, as the ifp fields are set in ipv6_add_addr now and ipv6_ifa_notify is called (and has been called) through addrconf_dad_start. 2. The removal of the whole block under ifp->lock in inet6_addr_add is okay, too, as tstamp is initialized to jiffies in ipv6_add_addr. Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet')
0 files changed, 0 insertions, 0 deletions