Activity log
- Created & dismissed (max. allowed matches exceeded) suggestion
can: isotp: use unconditional synchronize_rcu() in isotp_release()
In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.
References
Affected products
- =<6.6.*
- =<*
- <b88a511308779c225005d7994b8744561bdbafbc
- <5.13
- =<7.1.*
- =<5.10.*
- <6280eda96e0707264849fa7d036fed873c1f8a6d
- =<6.18.*
- <9b1a02e0d980ac6b0e36a90378f847062f81d7e4
- =<6.1.*
- <5.14
- ==ebf91625b3e404bd2b4b694c7ee71c1e8f8bd08f
- <cb6abc584a1bfab107ac003d64948a4aef1730aa
- =<6.12.*
- =<5.15.*
- <15413a082df69175c2f96aeab4c26fe1ff7cff03
- <59672aa4bcd8d32172c1ff6a179583981d6acabc
- <5.10.261
- <945d9894502cd9124f5d676181c542ed2000f7c0
- ==5.14
- ==80c6ddf771df2ef786f28c1ca5919b3f1080091b
- <5.14
- <b8278ff605187ef3fa0f2705e93251cce4c4f8ee