Race Condition Affecting kernel-zfcpdump package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNELZFCPDUMP-18337286
- published28 Jul 2026
- disclosed25 Jul 2026
Introduced: 25 Jul 2026
NewCVE-2026-64363 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-zfcpdump.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump package and not the kernel-zfcpdump package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
HID: appleir: fix UAF on pending key_up_timer in remove()
appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open.
key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it.
A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev.
Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down.
The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch.
This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2507281
- https://access.redhat.com/security/cve/CVE-2026-64363
- https://git.kernel.org/stable/c/05e3decc55d1deca9410e0eb36466651fcbe57a5
- https://git.kernel.org/stable/c/3755f6e25776b8b12ddf062f9b573f05090e4034
- https://git.kernel.org/stable/c/37a52c61d4f78153c38ae1f7491dfcc8ac828dcf
- https://git.kernel.org/stable/c/3d30a0bb0e79621ae921b487835c56198adfafa3
- https://git.kernel.org/stable/c/6b0838e86da88b1d3bff86f19761ff25af73eaca
- https://git.kernel.org/stable/c/75fe87e19d8aff81eb2c64d15d244ab8da4de945
- https://git.kernel.org/stable/c/89ef67359672bf4cd6921524e39f61648fe38c0f
- https://git.kernel.org/stable/c/b363d964ca829c1761c9f04188dfa28f90b0f2d4