CVE-2023-53768

regmap-irq: Fix out-of-bounds access when allocating config buffers

HIGH
7.8
CVSS Score
Published: December 8, 2025 at 01:19 AM UTC
Updated: August 5, 2026 at 10:24 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%

Description

In the Linux kernel, the following vulnerability has been resolved: regmap-irq: Fix out-of-bounds access when allocating config buffers When allocating the 2D array for handling IRQ type registers in regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix with num_config_bases rows and num_config_regs columns. This is currently handled by allocating a buffer to hold a pointer for each row (i.e. num_config_bases). After that, the logic attempts to allocate the memory required to hold the register configuration for each row. However, instead of doing this allocation for each row (i.e. num_config_bases allocations), the logic erroneously does this allocation num_config_regs number of times. This scenario can lead to out-of-bounds accesses when num_config_regs is greater than num_config_bases. Fix this by updating the terminating condition of the loop that allocates the memory for holding the register configuration to allocate memory only for each row in the matrix. Amit Pundir reported a crash that was occurring on his db845c device due to memory corruption (see "Closes" tag for Amit's report). The KASAN report below helped narrow it down to this issue: [ 14.033877][ T1] ================================================================== [ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364 [ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1 [ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850 [ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8 [ 14.255669][ T1] The buggy address is located 0 bytes inside of [ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858)

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.0 ≤ v < 6.1.406.0 ≤ v < 6.4.56.0 ≤ v < 6.56.0faa87ce9196dbb074d75bd4aecb8bacf18f19b4e
Vendor states this is fixed in 6e7b2337ecd028bd888a1a0be4115b8a88faf838 (fixed)
Vendor states this is fixed in 963b54df82b6d6206d7def273390bf3f7af558e1 (fixed)
Vendor states this is fixed in b1a726ad33e585e3d9fa70712df31ae105e4532c (fixed)
Vendor states this is fixed in 6.0 (unaffected)
Vendor states this is fixed in 6.1.40 (unaffected)
Vendor states this is fixed in 6.4.5 (unaffected)
Vendor states this is fixed in 6.5 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusDEFERRED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card