* Re: Semantic Bug: Privilege Bypass in timerfd for 4.4.y
[not found] <PR2PR09MB3180C560FF0F6CAEE9654A47F85E9@PR2PR09MB3180.eurprd09.prod.outlook.com>
@ 2021-04-30 11:40 ` Greg KH
0 siblings, 0 replies; only message in thread
From: Greg KH @ 2021-04-30 11:40 UTC (permalink / raw)
To: Kasper Zwijsen
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org,
security@kernel.org, stable
On Fri, Apr 30, 2021 at 10:57:59AM +0000, Kasper Zwijsen wrote:
> Dear Thomas Gleixner,
>
>
> I believe I have found a semantic security bug in the form of a missing capability check in the timerfd_create and timerfd_settime system calls for the 4.4.y LTS kernel.
>
> In this commit: https://github.com/torvalds/linux/commit/2895a5e5b3ae78d9923a91fce405d4a2f32c4309,
> capability checks for CAP_WAKE_ALARM were added for creating and setting a CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM.
> This security patch was applied to all but one LTS kernel, namely 4.4.y.
That is because it showed up in the 4.8 release, there was nothing to
"apply" to any newer kernels :)
> It is therefore still possible for a user process without any privileges to create and set such a timer, resulting in the process being able to wake up the system.
>
> The man pages state that creating or setting such a timer requires privileges. Similarly, the timer_create system call does check the correct permissions.
> I therefore believe this is unintended and a semantic bug.
> I have tested the original patch and found that it can simply be applied to the latest 4.4.y kernel (4.4.268 as of right now) without any issues.
> The patch: https://lore.kernel.org/patchwork/patch/686888/
I've now queued this up for the next 4.4.y release. In the future, you
should just email the stable@vger.kernel.org address any git commit ids
that you feel need to be backported.
thanks!
greg k-h
^ permalink raw reply [flat|nested] only message in thread