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)
Jan 10 2024, 2:49 PM
Unknown Object (File)
Dec 25 2023, 12:06 PM
Unknown Object (File)
Dec 12 2023, 6:17 AM
Unknown Object (File)
Nov 27 2023, 9:19 AM
Unknown Object (File)
Nov 26 2023, 5:44 AM
Unknown Object (File)
Nov 22 2023, 6:38 PM
Unknown Object (File)
Nov 22 2023, 6:27 PM
Unknown Object (File)
Nov 13 2023, 5:58 AM
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.