In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
can: bcm: add locking when updating filter and timer values<\/p>\n
KCSAN detected a simultaneous access to timer values that can be
\noverwritten in bcm_rx_setup() when updating timer and filter content
\nwhile bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler()
\nrun concurrently on incoming CAN traffic.<\/p>\n
Protect the timer (ival1\/ival2\/kt_ival1\/kt_ival2\/kt_lastmsg) and filter
\n(nframes\/flags\/frames\/last_frames) updates in bcm_rx_setup() with a new
\nper-op bcm_rx_update_lock, taken with the matching scope in the RX
\nhandlers. memcpy_from_msg() is staged into a temporary buffer before the
\nlock is taken, since it can sleep and must not run under a spinlock.<\/p>\n
hrtimer_cancel() is always called without bcm_rx_update_lock held, since
\nbcm_rx_timeout_handler()\/bcm_rx_thr_handler() take the same lock and a
\nrunning callback would otherwise deadlock against the canceller.<\/p>\n
Also close a related race: bcm_rx_setup() cleared the RTR flag in the
\nstored reply frame’s can_id as a separate, unprotected step after the
\nframe content was already installed, so a concurrent bcm_rx_handler()
\ncould transmit a stale reply with CAN_RTR_FLAG still set. Fold that
\nnormalization into the initial frame preparation instead (on the staged
\nbuffer for updates, directly on op->frames pre-registration for new
\nops), so the installed frame is always atomically self-consistent.<\/p>\n
bcm_rx_handler()’s RX_RTR_FRAME check now takes a lock-protected
\nsnapshot of op->flags before deciding whether to call bcm_can_tx(),
\nbut does not hold the lock across that call.<\/p>\n
Also take a lock-protected snapshot of the currframe in bcm_can_tx()
\nto avoid partly overwrites by content updates in bcm_tx_setup().
\nFinally check if a TX_RESET_MULTI_IDX\/SETTIMER might have reset
\nop->currframe between the two locked sections in bcm_can_tx().<\/p>\n
Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler().
\nkt_ival2 may have been concurrently cleared by bcm_rx_setup() before it
\ncancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
can: bcm: add locking when updating filter and timer values<\/p>\n
KCSAN detected a simultaneous access to timer values that can be
\noverw<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-6787","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/6787","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}