vulnerability
Amazon Linux 2023: CVE-2025-37949: Important priority package update for kernel (Multiple Advisories)
| Severity | CVSS | Published | Added | Modified |
|---|---|---|---|---|
| 4 | (AV:L/AC:M/Au:M/C:N/I:N/A:C) | May 20, 2025 | Aug 5, 2025 | Aug 5, 2025 |
Severity
4
CVSS
(AV:L/AC:M/Au:M/C:N/I:N/A:C)
Published
May 20, 2025
Added
Aug 5, 2025
Modified
Aug 5, 2025
Description
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
<TASK>
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems
like it was xs_wake_up() in this case.
It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed
data.
Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.
Change to keeping two krefs on each request. One for the caller, and
one for xenbus_thread. Each will kref_put() when finished, and the last
will free it.
This use of kref matches the description in
Documentation/core-api/kref.rst
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
<TASK>
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems
like it was xs_wake_up() in this case.
It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed
data.
Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.
Change to keeping two krefs on each request. One for the caller, and
one for xenbus_thread. Each will kref_put() when finished, and the last
will free it.
This use of kref matches the description in
Documentation/core-api/kref.rst
Solutions
amazon-linux-2023-upgrade-bpftoolamazon-linux-2023-upgrade-bpftool-debuginfoamazon-linux-2023-upgrade-kernelamazon-linux-2023-upgrade-kernel6-12amazon-linux-2023-upgrade-kernel6-12-debuginfoamazon-linux-2023-upgrade-kernel6-12-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel6-12-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel6-12-modules-extraamazon-linux-2023-upgrade-kernel-debuginfoamazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel-develamazon-linux-2023-upgrade-kernel-headersamazon-linux-2023-upgrade-kernel-libbpfamazon-linux-2023-upgrade-kernel-libbpf-debuginfoamazon-linux-2023-upgrade-kernel-libbpf-develamazon-linux-2023-upgrade-kernel-libbpf-staticamazon-linux-2023-upgrade-kernel-livepatch-6-1-140-154-222amazon-linux-2023-upgrade-kernel-livepatch-6-12-29-33-102amazon-linux-2023-upgrade-kernel-modules-extraamazon-linux-2023-upgrade-kernel-modules-extra-commonamazon-linux-2023-upgrade-kernel-toolsamazon-linux-2023-upgrade-kernel-tools-debuginfoamazon-linux-2023-upgrade-kernel-tools-develamazon-linux-2023-upgrade-perfamazon-linux-2023-upgrade-perf6-12amazon-linux-2023-upgrade-perf6-12-debuginfoamazon-linux-2023-upgrade-perf-debuginfoamazon-linux-2023-upgrade-python3-perfamazon-linux-2023-upgrade-python3-perf6-12amazon-linux-2023-upgrade-python3-perf6-12-debuginfoamazon-linux-2023-upgrade-python3-perf-debuginfo
NEW
Explore Exposure Command
Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.