Page MenuHomeFreeBSD

rip6: Fix a lock order reversal in rip6_bind()
ClosedPublic

Authored by markj on Jun 13 2022, 3:56 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 20, 12:54 AM
Unknown Object (File)
Sun, Oct 20, 12:54 AM
Unknown Object (File)
Sun, Oct 20, 12:54 AM
Unknown Object (File)
Sun, Oct 20, 12:33 AM
Unknown Object (File)
Sep 23 2024, 11:34 PM
Unknown Object (File)
Sep 23 2024, 8:34 AM
Unknown Object (File)
Sep 21 2024, 11:51 AM
Unknown Object (File)
Sep 15 2024, 6:54 PM
Subscribers

Details

Summary

See also commit 71a1539e3783.

Reported by: syzbot+9b461b6a07a83cc10daa@syzkaller.appspotmail.com
Reported by: syzbot+b6ce0aec16f5fdab3282@syzkaller.appspotmail.com

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Jun 13 2022, 3:56 PM

The patch of course brings locking into correct order. However, at a glance I don't see any good reason to lock INP_INFO_WLOCK() for this assignment on a single inp->inp6p_laddr. Maybe this is some feature of IPv6, that I don't know, though.

This revision is now accepted and ready to land.Jun 13 2022, 6:28 PM

The patch of course brings locking into correct order. However, at a glance I don't see any good reason to lock INP_INFO_WLOCK() for this assignment on a single inp->inp6p_laddr. Maybe this is some feature of IPv6, that I don't know, though.

I wondered the same thing. rip6_connect() has the same "feature." I am inclined to leave it alone for now.

This revision was automatically updated to reflect the committed changes.