NULL Pointer Dereference Affecting kernel-rt-kvm 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-KERNELRTKVM-18642063
- published14 Aug 2026
- disclosed10 Aug 2026
Introduced: 10 Aug 2026
NewCVE-2026-68378 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-rt-kvm.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-kvm package and not the kernel-rt-kvm 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:
dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()
When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().
This happens under the following conditions:
- A pin is registered with two or more dpll devices (dpll_A, dpll_B)
- The pin has ref_sync pairs with other pins
- During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs
- But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray
- When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs
- The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it
BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70
Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2513257
- https://access.redhat.com/security/cve/CVE-2026-68378
- https://git.kernel.org/stable/c/4b3e6b9fdaeb40c6a2f7c41db3888b6ee628bdd2
- https://git.kernel.org/stable/c/51c2fcc4cd2e4c52bd1970558f6e5356fdc51154
- https://git.kernel.org/stable/c/66fbe0499ef517ab161b96c49886a891851f6481
- https://git.kernel.org/stable/c/d2e914a4a0d0f753dbae830264850d044026167c