🇰🇷 한글 설명
Linux 커널의 CAN(Controller Area Network) 드라이버 내 bcm 모듈에서 타이머 및 필터 값 업데이트 시 동시 접근으로 인한 레이스 컨디션 취약점이 발견되었습니다. KCSAN에 의해 탐지된 이 문제는 여러 핸들러가 동시에 실행될 때 데이터가 덮어씌워지거나 일관성이 깨질 수 있는 문제를 포함합니다.
💡 쉬운 설명
여러 작업이 동시에 CAN 통신 데이터를 처리하는 과정에서 데이터가 서로 충돌하여 잘못된 값이 저장될 수 있는 문제입니다. 이로 인해 통신 데이터가 꼬이거나 시스템이 예상치 못한 동작을 할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking when updating filter and timer values
KCSAN detected a simultaneous access to timer values that can be
overwritten in bcm_rx_setup() when updating timer and filter content
while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler()
run concurrently on incoming CAN traffic.
Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter
(nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new
per-op bcm_rx_update_lock, taken with the matching scope in the RX
handlers. memcpy_from_msg() is staged into a temporary buffer before the
lock is taken, since it can sleep and must not run under a spinlock.
hrtimer_cancel() is always called without bcm_rx_update_lock held, since
bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a
running callback would otherwise deadlock against the canceller.
Also close a related race: bcm_rx_setup() cleared the RTR flag in the
stored reply frame's can_id as a separate, unprotected step after the
frame content was already installed, so a concurrent bcm_rx_handler()
could transmit a stale reply with CAN_RTR_FLAG still set. Fold that
normalization into the initial frame preparation instead (on the staged
buffer for updates, directly on op->frames pre-registration for new
ops), so the installed frame is always atomically self-consistent.
bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected
snapshot of op->flags before deciding whether to call bcm_can_tx(),
but does not hold the lock across that call.
Also take a lock-protected snapshot of the currframe in bcm_can_tx()
to avoid partly overwrites by content updates in bcm_tx_setup().
Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset
op->currframe between the two locked sections in bcm_can_tx().
Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler().
kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it
cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.
📍 영향받는 시스템
Linux kernel (bcm CAN driver module)
⚔️ 공격 벡터
동시에 발생하는 CAN 트래픽을 이용한 레이스 컨디션 유발 (Race Condition)
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 bcm_rx_update_lock이 적용된 패치를 적용해야 합니다.
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인합니다.