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

--vmWVJi+5d1RZ5heS
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

> > this looks like it does not need special drivers and is not that easy
> > to mitigate (CONFIG_POSIX_TIMERS=3Dn...):
> >=20
> > https://git.kernel.org/pub/scm/linux/security/vulns.git/commit/?id=3D08=
1d2ff9592751aa400828237f17c108e4e1f513
> >=20
> > Early releases?
>=20
> No cool name, no logo, and no website? Aint doing no release for that!
>=20
> So... this is crasher, and you need local access for it. In my eyes,
> it is below "Dirty Cow" in severity.

So .. apparently Sasha or his robots believe this may be exploitable:

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 write
    primitive.

So far, I don't see distributions acting the way they did on "Dirty
Cow":

https://security-tracker.debian.org/tracker/CVE-2026-64560

(Note the auto-generated, useless description).

So the other two one-patch releases are. Not good, but not "Dirty Cow"
level of dangerous, either, AFAICT.

    Linux 6.12.99
commit 41fb1f3c8a712eba4b1eae0a9023e80007a71413
Author: Lorenzo Stoakes <[email protected]>
Date:   Tue Sep 24 21:10:23 2024 +0100

    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 handled
    the same as an error in all callers, with some translating this into an
    -ESRCH error.
=2E...
    Linux 6.12.98
commit 913e7b4459d6eef807bb8088b39b890ed6a74ee3
Author: Yun Zhou <[email protected]>
Date:   Sat Jul 25 10:40:29 2026 +0800

    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 -EXDEV'
    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 label,
    leaking the file reference.

Best regards,
									Pavel
--vmWVJi+5d1RZ5heS
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCamvF1gAKCRAw5/Bqldv6
8rIrAKCjhyg+obrRK4oy3O0wGHG1mrMRvwCgw4olikTMmKxLp8qgALVDCNKzN20=
=hFjv
-----END PGP SIGNATURE-----

--vmWVJi+5d1RZ5heS--