CVE-2026-64560

CVE-2026-64560

[Jan Kiszka]

Hi all,

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?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: CVE-2026-64560

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 651 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.

https://lwn.net/Articles/1086226/

But this is 6.12.100. Something tells me 6.12.99 and .98 are fixing
similar issues. So... I guess we should investigate some more.

Best regards,
								Pavel


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

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

[Pavel Machek]

[-- 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 --]

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

[Jan Kiszka]

On 30.07.26 23:44, Pavel Machek wrote:
> 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).

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

> 
> 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

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

-- 
Siemens AG, Foundational Technologies
Linux Expert Center