CVE-2026-72047 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out().
This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel
address and generally results in an oops.
Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture.
The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs.
Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the linux kernel's ieee802154 ca8210 driver implementation where a pointer truncation issue occurs during fifo operations on 64-bit architectures. This flaw stems from improper handling of pointer sizes when data is passed through kernel fifos, specifically affecting the communication between test interrupt driver write and user read functions. The core technical issue manifests when kmalloc'd buffer pointers are exchanged via struct kfifo mechanisms using a hardcoded byte count of four bytes for kfifo_in() and kfifo_out() operations.
The fundamental flaw arises from architecture-dependent pointer size handling where 32-bit systems naturally align with the 4-byte literal specification, but 64-bit systems encounter truncation when only the lower 4 bytes of an 8-byte pointer are written to the fifo. This architectural mismatch creates a scenario where the upper 4 bytes of the pointer remain uninitialized stack data when read back by the consumer function. The vulnerability demonstrates a classic case of improper memory management and pointer arithmetic that violates security principles.
The operational impact of this vulnerability is severe as it allows for arbitrary kernel address dereferencing during the first access of the reconstructed pointer from the fifo buffer. This condition typically results in kernel oops or system crashes, effectively creating a denial-of-service scenario while potentially enabling privilege escalation attacks. The vulnerability affects any 64-bit kernel build with the specific configuration option CONFIG_IEEE802154_CA8210_DEBUGFS=y enabled, making it exploitable across various modern linux distributions and embedded systems.
The root cause aligns with CWE-194, which addresses improper handling of pointer truncation during data transfer operations, and demonstrates characteristics consistent with ATT&CK technique T1068 by creating a condition that could allow privilege escalation. The vulnerability has remained latent since its introduction in 2017 due to the common deployment of this driver on 32-bit microcontrollers where the issue does not manifest. This oversight highlights the importance of architecture-agnostic code review practices and proper testing across different system configurations.
Mitigation strategies should focus on implementing sizeof() operations that dynamically adjust byte counts based on pointer width rather than using hardcoded values. The fix requires changing the kfifo_in() and kfifo_out() calls to use sizeof(fifo_buffer) instead of the literal '4' value, ensuring consistent behavior across both 32-bit and 64-bit architectures. Additionally, comprehensive testing should be implemented to verify that all pointer-based fifo operations maintain proper size alignment regardless of target architecture, addressing similar issues in other kernel subsystems through systematic code review processes.