Look up another CVE · open CVE-2024-27062 in the interactive tracker
CVE-2024-27062
nouveau: lock the client object tree.
Published 2024-05-01 (2 years ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-27062 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.7.12-1 | Update the kernel and reboot. Fixed in 6.7.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
drivers/gpu/drm/nouveau/nvkm/core/client.c
drivers/gpu/drm/nouveau/nvkm/core/object.c
- What this is
- DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUSMAINTAINERS section matched on drivers/gpu/drm/nouveau/ · dri-devel@lists.freedesktop.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2024-05-01 (2 years ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.3 | 6.6.24 | 6887314f5356 |
| 4.3 | 6.7.12 | 96c875184417 |
| 4.3 | 6.8 | b7cc4ff787a5 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code is reached through the nouveau DRM device node — `DRM_NOUVEAU_NVIF` ioctls on `/dev/dri/renderD128` and page faults on mmap'd GEM buffer objects. No network or physical component is involved.
- AC:LAttack complexity, low
- The attacker controls both sides of the race entirely within their own process — one thread issuing NVIF object NEW/DEL ioctls while another touches mmap'd VRAM BOs to drive `nouveau_ttm_io_mem_reserve()` → `nvkm_object_search()`; the three paths hold three different locks so no serialization exists. The race was hit unintentionally by a normal `deqp-vk` conformance run, confirming the window is trivially wide.
- PR:LPrivileges required, low
- Only an open file descriptor on the nouveau render node is required; nouveau advertises `DRIVER_RENDER` and `nouveau_drm_ioctl()` dispatches the NVIF ioctl before `drm_ioctl()`, so not even DRM_AUTH/DRM_MASTER is checked. Any local user with GPU access — a normal desktop session user, an Android app, or a container with the render node exposed — qualifies.
- UI:NUser interaction, none
- The attacking process performs all steps itself: opening the render node, allocating and mmap'ing buffer objects, and spawning the racing threads. No victim action is needed.
- S:UScope, unchanged
- Corruption is confined to kernel memory within the same security authority; this is a standard local kernel privilege-escalation surface with no VM, IOMMU, or sandbox boundary crossed.
- C:HConfidentiality impact, high
- A torn rb-tree traversal dereferences attacker-influenceable wild pointers (`rb_entry()` on garbage `node`), and a lookup that "succeeds" on a stale node returns a wrong/freed `nvkm_object` that `nvkm_ioctl_path()` then reads (`object->route`, `object->token`) and uses for `nvkm_ioctl_rd`, yielding arbitrary kernel-memory and MMIO disclosure.
- I:HIntegrity impact, high
- Unserialized concurrent `rb_insert_color()`/`rb_erase()` rebalancing writes through pointers of a corrupted tree, and a bogus object returned to `nvkm_ioctl_path()` is dispatched via `object->func->mthd/wr32/map` — an indirect call through a function pointer in potentially freed memory, giving control-flow hijack and arbitrary write potential.
- A:HAvailability impact, high
- The reported failure is an immediately reproducible general protection fault on a non-canonical address in `nvkm_object_search()`, killing the task and leaving the GPU/kernel in an inconsistent state; it can be triggered repeatedly by any local user with render-node access.