On 22.01.22 11:30, Greg KH wrote:
On Sat, Jan 22, 2022 at 06:25:06PM +0800, Ziyang Xuan wrote:Stopping tasklet and hrtimer rely on the active state of tasklet and hrtimer sequentially in bcm_remove_op(), the op object will be freed if they are all unactive. Assume the hrtimer timeout is short, the hrtimer cb has been excuted after tasklet conditional judgment which must be false after last round tasklet_kill() and before condition hrtimer_active(), it is false when execute to hrtimer_active(). Bug is triggerd, because the stopping action is end and the op object will be freed, but the tasklet is scheduled. The resources of the op object will occur UAF bug. Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}' to 'do {...} while ()' to fix the op UAF problem. Fixes: a06393ed0316 ("can: bcm: fix hrtimer/tasklet termination in bcm op removal") Reported-by: syzbot+5ca851459ed04c778d1d@xxxxxxxxxxxxxxxxxxxxxxxxx Cc: stable@xxxxxxxxxxxxxxx Signed-off-by: Ziyang Xuan <william.xuanziyang@xxxxxxxxxx> --- net/can/bcm.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)What is the git commit id of this change in Linus's tree?
Linus' tree has been fixed by removing the tasklet implementation and replacing it with a HRTIMER_MODE_SOFT approach here:
commit bf74aa86e111a ("can: bcm: switch timer to HRTIMER_MODE_SOFT and remove hrtimer_tasklet")
This patch from Ziyang Xuan fixes the 'old' tasklet implementation for 'old' stable kernels that lack the HRTIMER_MODE_SOFT infrastructure.
Acked-by: Oliver Hartkopp <socketcan@xxxxxxxxxxxx> Best regards, Oliver
thanks, greg k-h
