NULL Pointer Dereference Affecting kernel-64k-debug-modules-partner 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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-RHEL9-KERNEL64KDEBUGMODULESPARTNER-8249090
- published23 Oct 2024
- disclosed21 Oct 2024
Introduced: 21 Oct 2024
CVE-2022-48969 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 kernel-64k-debug-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug-modules-partner package and not the kernel-64k-debug-modules-partner package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Fix NULL sring after live migration
A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260
finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]---
xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed
There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time
References
- https://access.redhat.com/security/cve/CVE-2022-48969
- https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd
- https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9
- https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a
- https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050
- https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda
- https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84