CVE-2025-68367
NoneCVSS
—
EPSS
0.2%
Published
Dec 24, 2025
CISA due date
—
Cloudanix analysis
A timing flaw in the Linux kernel can let two programs interfere with each other when both try to enable mouse emulation at the same moment, producing warnings and possible instability.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Other
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in mac_hid_toggle_emumouse allows concurrent writes to the mac-hid emulation sysctl to read an old value outside the mutex, resulting in duplicate input_register_handler calls and a list_add double-add warning.
Why it matters to the business
Kernel warning messages and potential instability on systems exposing the mac-hid sysctl when multiple processes write to it concurrently; low exploitation likelihood reduces urgency but still requires patching for stability.
How an attack unfolds
An attacker starts two processes that simultaneously issue writes of value 1 to the mac-hid emulation sysctl; both read the prior zero value before either acquires the mutex, causing both to execute mac_hid_start_emulation and trigger the double list_add.
How to fix it
Apply the upstream fix that moves the old_val read inside the mutex-protected region; update Linux kernel to commit d5f1d40fd342b589420de7508b4c748fcf28122e or later; for graphicsmagick packages upgrade to 1.3.45-r30 or equivalent fixed release.
How to confirm the fix worked
Inspect the mac_hid_toggle_emumouse implementation to confirm the old_val read occurs after mutex acquisition; verify absence of the list_add double-add warning under concurrent sysctl writes; confirm presence of the referenced kernel commit or package version 1.3.45-r30.
Typical attack path
- Identify a system exposing the mac-hid emulation sysctl interface
- Spawn two concurrent processes that both write value 1 to the sysctl
- Trigger mac_hid_toggle_emumouse in each process without mutex serialization
- Cause duplicate input handler registration and list_add warning
How to detect it
Search kernel logs and dmesg output for the exact list_add double add warning mentioning mac_hid_toggle_emumouse or input_register_handler; correlate with processes writing to /proc/sys/mac_hid or related sysctl paths; review audit logs for concurrent vfs_write calls to the emulation handler.
- list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100
- WARNING: CPU:.* at lib/list_debug.c:.* __list_add_valid_or_report
- mac_hid_toggle_emumouse
- mac_hid_start_emulation
- input_register_handler
What your security team should do
- Prioritize kernel updates on systems that expose mac-hid sysctls
- Audit workloads for concurrent writes to mac-hid emulation controls
- Monitor kernel logs for list_add double-add warnings as an early indicator
- Track EPSS and KEV updates given the low current scores but potential for future increase
The record
In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 2.6.34 | 5.10.248 |
| Linux | Kernel | 2.6.34 | 6.12.63 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.26.1.160000.2.7 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.26.1 |
| openSUSE:Tumbleweed | kernel-source | 0 | 6.18.5-1.1 |
| openSUSE:Tumbleweed | kernel-source-longterm | 0 | 6.18.16-1.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel