Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 648332 - net-misc/netifrc-0.5.1: possible race condition in _add_route
Summary: net-misc/netifrc-0.5.1: possible race condition in _add_route
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: netifrc Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-20 20:16 UTC by William Hubbs
Modified: 2020-05-31 10:34 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Hubbs gentoo-dev 2018-02-20 20:16:06 UTC
There is a possible race condition in _add_route that is causing"ip
route add" to add a route before the "ip addr add" command takes effect.
It appears to happen at random on multi-homed hosts. When it does
happen, the affected interface has an address, but no default route.
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-02-20 22:55:50 UTC
I need a LOT more context on where you're seeing this.

_add_address calls 'ip addr add' and does check the return code. From net.lo, _add_route is called much later than _add_address.
Comment 2 Wolfgang Müller 2019-07-06 21:20:14 UTC
A similar thing just happened to me on a multi-homed system, though specifically with multiple IPv6 addresses and a preferred source address in ip route.

Since the kernel checks whether a source address is actually configured on an interface (I'm assuming tentative addresses don't count), ip route should possibly wait until DAD is done on all addresses.

Of course I cannot say whether this was the original issue, though this bug seems to describe my issue well.
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-05-31 05:34:47 UTC
(In reply to Wynn Wolf Arbor from comment #2)
> A similar thing just happened to me on a multi-homed system, though
> specifically with multiple IPv6 addresses and a preferred source address in
> ip route.
> 
> Since the kernel checks whether a source address is actually configured on
> an interface (I'm assuming tentative addresses don't count), ip route should
> possibly wait until DAD is done on all addresses.
> 
> Of course I cannot say whether this was the original issue, though this bug
> seems to describe my issue well.

Having seen lots of systems where DAD never finishes (the reason I added the dad_timeout knob), I feel there's a lot of risk to doing this by default.


whubbs: was your original case on v4 (where this is no DAD) or v6
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-05-31 05:35:17 UTC
Wynn: you were not on the CC list, can you please see my comment 3?
Comment 5 Wolfgang Müller 2020-05-31 10:34:31 UTC
I have to admit that I completely forgot this bug existed, since I solved it by adding "nodad" to the affected IPv6 addresses in conf.d/net. For this particular setup I do not have a need for DAD anyway.

> Having seen lots of systems where DAD never finishes (the reason I added the
> dad_timeout knob), I feel there's a lot of risk to doing this by default.
I definitely agree with this. I haven't seen such systems yet myself, but if this is anything anyone is consistently seeing, we should not rely on DAD finishing consistently. I don't know when exactly dad_timeout was added, but having ip route wait for a maximum of dad_timeout seems like a decent workaround. Note that I have not looked at netifrc in quite a while now, though.

I have not seen any issue like this with v4 addresses in all my years.

If there's anything else I can do to help, do let me know.