Re: [cip-dev] CVE-2026-64560

On 30.07.26 23:44, Pavel Machek wrote:
> Hi!
>=20
>>> this looks like it does not need special drivers and is not that easy
>>> to mitigate (CONFIG_POSIX_TIMERS=3Dn...):
>>>
>>> https://git.kernel.org/pub/scm/linux/security/vulns.git/commit/?id=3D08=
1d2ff9592751aa400828237f17c108e4e1f513
>>>
>>> Early releases?
>>
>> No cool name, no logo, and no website? Aint doing no release for that!
>>
>> So... this is crasher, and you need local access for it. In my eyes,
>> it is below "Dirty Cow" in severity.
>=20
> So .. apparently Sasha or his robots believe this may be exploitable:
>=20
> I:H -`collect_timerqueue()` writes into freed memory
>     (`ctmr->firing`, `ctmr->handling`, rbtree rebalancing, list
>     insertion) and the `do_cpu_nanosleep()` variant does so into a
>     live, attacker-groomed kernel stack frame, followed by
>     `cpu_timer_fire()` dereferencing attacker-controlled
>     `it_process`/`it_signal` =E2=80=94 a control-flow-hijack-capable writ=
e
>     primitive.
>=20
> So far, I don't see distributions acting the way they did on "Dirty
> Cow":
>=20
> https://security-tracker.debian.org/tracker/CVE-2026-64560
>=20
> (Note the auto-generated, useless description).

That is a 1:1 pick-up of the commit message, "just" truncated where the
CVE record overflew (hope /that/ is not exploitable ;)).

>=20
> So the other two one-patch releases are. Not good, but not "Dirty Cow"
> level of dangerous, either, AFAICT.
>=20
>     Linux 6.12.99
> commit 41fb1f3c8a712eba4b1eae0a9023e80007a71413
> Author: Lorenzo Stoakes <[email protected]>
> Date:   Tue Sep 24 21:10:23 2024 +0100
>=20
>     mm: refactor mm_access() to not return NULL
>    =20
>     [ Upstream commit cd3f8467afd470ccab0de2fbc7c76664af4a0bac ]
>    =20
>     mm_access() can return NULL if the mm is not found, but this is handl=
ed
>     the same as an error in all callers, with some translating this into =
an
>     -ESRCH error.
> ....
>     Linux 6.12.98
> commit 913e7b4459d6eef807bb8088b39b890ed6a74ee3
> Author: Yun Zhou <[email protected]>
> Date:   Sat Jul 25 10:40:29 2026 +0800
>=20
>     ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation
>    =20
>     The backport of upstream commit c143957520c6 ("ext4: validate donor
>     file superblock early in EXT4_IOC_MOVE_EXT") uses a bare 'return -EXD=
EV'
>     which is safe upstream because the fd is managed via CLASS(fd) with
>     automatic cleanup (commit 8152f8201088 ("fdget(), more trivial
>     conversions")).
>    =20
>     However, on 6.12.y the ioctl still uses the traditional fdget/fdput
>     pattern, so the bare return bypasses fdput(donor) at the mext_out lab=
el,
>     leaking the file reference.
>=20
> Best regards,
> 									Pavel

Thanks for checking.

We should keep in eye on it, specifically regarding exploitation and
reactions of others. I agree that we do not need to hurry at this stage.

Jan

--=20
Siemens AG, Foundational Technologies
Linux Expert Center