[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220203204518.GA18824@duo.ucw.cz>
Date: Thu, 3 Feb 2022 21:45:18 +0100
From: Pavel Machek <pavel@...x.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
syzbot+5ca851459ed04c778d1d@...kaller.appspotmail.com,
Ziyang Xuan <william.xuanziyang@...wei.com>,
Oliver Hartkopp <socketcan@...tkopp.net>
Subject: Re: [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op
Hi!
> From: Ziyang Xuan <william.xuanziyang@...wei.com>
>
> 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.
I don't see this commit in mainline or next kernels. What is going on
here? Is it one of those "only needed in -stable" things? Or do we
still need to fix it in the mainline?
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists