https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289121
Bug ID: 289121
Summary: A time-of-check to time-of-use race exists in
sysctl_requested_fec() of the cxgbe subsystem
Product: Base System
Version: 14.3-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Summary
In sysctl_requested_fec(), the output string is chosen via a ternary that reads
lc->requested_fec twice without synchronization:
lc->requested_fec == FEC_AUTO ? -1 :
(lc->requested_fec & (M_FW_PORT_CAP32_FEC | FEC_MODULE))
Because lc->requested_fec may change between the check and the use, the
“lc->requested_fec == FEC_AUTO” test can pass/fail on a stale value, and the
masked use can observe a concurrent FEC_AUTO, yielding 0 (since FEC_AUTO &
(M_FW_PORT_CAP32_FEC | FEC_MODULE) == 0). The result “0” is then handed to
sysctl_handle_string() as the old value. However, under the allowed mask no
real FEC combination produces 0; real FECs live in bit0..2 (FEC_RS=1<<0,
FEC_BASER_RS=1<<1, FEC_NONE=1<<2), while pseudo FECs start at bit5
(FEC_AUTO=1<<5, FEC_MODULE=1<<6). AUTO should be serialized as “-1”, not “0”.
Impact
• Wrong interface semantics: the old value reported to user space can become
“0”, which encodes neither AUTO (-1) nor any valid real-FEC bitset, misleading
management tools and scripts and causing faulty decisions.
Suggested fix
Snapshot lc->requested_fec once into local variables and compute from that
single snapshot, instead of repeatedly reading shared fields.
--
You are receiving this mail because:
You are the assignee for the bug.
