CVE-2023-53383 in Linuxinfo

Summary

by MITRE • 09/18/2025

In the Linux kernel, the following vulnerability has been resolved:

irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4

The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs.

This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior.

>From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving.

The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL

Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."

This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4."


Writing to the chip alias region of the GICD_In{E} registers except
GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum.

To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the
SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 12/11/2025

The vulnerability described in CVE-2023-53383 represents a critical hardware-software interaction issue affecting NVIDIA server platforms based on the T241 chipset architecture. This flaw manifests as a hardware erratum known as T241-FABRIC-4 which fundamentally impacts the ARM Generic Interrupt Controller version 3 (GICv3) operation within multi-chip server environments. The issue specifically affects systems utilizing more than two T241 chips interconnected through the fabric, where each chip supports 320 extended SPIs, creating complex interrupt routing scenarios that expose the underlying hardware limitation.

The technical root cause of this vulnerability lies in the improper handling of AXI4 Stream packet interleaving within the system fabric when multiple interrupt transactions are simultaneously processed from different GIC instances. According to the erratum specifications, certain GICv3 commands generate multiple transfer packets that become interleaved during transmission across the inter-socket interface, leading to GIC state corruption. This corruption can manifest through kernel panics, system instability, and unpredictable interrupt handling behavior. The affected commands include register reads from GICD_I and GICD_N registers, 64-bit GICD register writes excluding GICD_IROUTERn*, and the ITS command MOVALL, with GICv4+ extensions adding additional complexity through commands like VMOVP, VMOVI, VMAPP, and 64-bit register accesses.

This vulnerability directly impacts system configurations exceeding single or dual socket deployments where multi-transfer packets must traverse the inter-socket AXI4 Stream interface between GIC instances. The operational impact is significant as it effectively prevents the use of GICv4 functionality while limiting GICv3 support to a workaround implementation. The issue demonstrates a classic hardware abstraction layer problem where the software implementation cannot adequately compensate for fundamental hardware design limitations, creating a cascading effect that affects system reliability and interrupt processing integrity. Systems with more than two sockets are particularly vulnerable, while single and dual socket configurations remain unaffected, indicating the problem is scale-dependent rather than universal.

The mitigation strategy implemented in the Linux kernel addresses this through a targeted workaround that ensures read accesses to GICD_In{E} registers are properly directed to the chip that owns the specific SPI, thereby preventing the state corruption scenarios. The solution specifically disables GICv4.x features to maintain system stability and implements a code change that makes the gic_configure_irq() function use the same alias region for both read and write operations to GICD_ICFGR, effectively standardizing the access pattern to prevent the interleaving issues. This approach aligns with the broader security principle of least privilege and system hardening, ensuring that interrupt handling remains predictable and stable even in complex multi-chip configurations. The workaround maintains backward compatibility while preventing the specific hardware interaction patterns that trigger the erratum, demonstrating a pragmatic approach to hardware-software co-design challenges. The vulnerability classification aligns with CWE-119, representing memory access violations due to improper handling of hardware state, and relates to ATT&CK technique T1068, involving local privilege escalation through kernel vulnerabilities that can be exploited to compromise system integrity.

Responsible

Linux

Reservation

09/17/2025

Disclosure

09/18/2025

Moderation

accepted

CPE

ready

EPSS

0.00134

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!