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

[Pavel Machek <pavel@nabladev.com>]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

Hi!

> > this looks like it does not need special drivers and is not that easy
> > to mitigate (CONFIG_POSIX_TIMERS=n...):
> > 
> > https://git.kernel.org/pub/scm/linux/security/vulns.git/commit/?id=081d2ff9592751aa400828237f17c108e4e1f513
> > 
> > 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.

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` — 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 <lorenzo.stoakes@oracle.com>
Date:   Tue Sep 24 21:10:23 2024 +0100

    mm: refactor mm_access() to not return NULL
    
    [ Upstream commit cd3f8467afd470ccab0de2fbc7c76664af4a0bac ]
    
    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.
....
    Linux 6.12.98
commit 913e7b4459d6eef807bb8088b39b890ed6a74ee3
Author: Yun Zhou <yun.zhou@windriver.com>
Date:   Sat Jul 25 10:40:29 2026 +0800

    ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation
    
    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")).
    
    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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]