The radvd daemon would not fail on privsep_init() errors, which could cause it to run with full root privileges when it should be running as an unprivileged user. (CVE-2011-3603) This is corrected in upstream git [1], [2], [3]. [1] https://github.com/reubenhwk/radvd/commit/2c50375043186e133f15135f4c93ca964238ee60 [2] https://github.com/reubenhwk/radvd/commit/074816cd0b37aac7b3209987e6e998f0a847b275 [3] https://github.com/reubenhwk/radvd/commit/7dc53cc3b792775369bf0b2f053a3f4ed5d87e3d Acknowledgements: Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.
The version of radvd shipped with Red Hat Enterprise Linux 4 and 5, does not have the "--singleprocess" config option, hence there is no privilege separation. The vulnerable code privsec_init() hence does not exists and therefore they are not vulnerable. The issue affects the version of radvd shipped with Red Hat Enterprise Linux 6. This issue affects the version of radvd shipped with Fedora 14 and 15.
Public via: http://thread.gmane.org/gmane.comp.security.oss.general/5973
Created radvd tracking bugs for this issue Affects: fedora-all [bug 744116]
Further investigations have revealed that this is not a security flaw at all. If privsep_init() fails, the only impact it would have is that radvd would run as a single process as radvd user (assuming "--username radvd" was used, which is the default configuration) More information at: http://thread.gmane.org/gmane.comp.security.oss.general/5973/focus=6015
Statement: A failure in privsep_init() does not cause radvd to run with full root privileges when invoked with the --username option specifying an unprivileged user. Rather it will run as a single process as the specified (unprivileged) radvd user, causing this issue to have no security impact (no unintended privilege elevation).