CVE-2023-53383
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-18

Last updated on: 2025-12-11

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-18
Last Modified
2025-12-11
Generated
2026-05-27
AI Q&A
2025-09-18
EPSS Evaluated
2026-05-25
NVD
CVE-2023-53383
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel to 6.1.30 (exc)
linux linux_kernel From 6.2 (inc) to 6.3.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a hardware erratum affecting NVIDIA T241 server platforms using more than two T241 chips interconnected. The issue causes unexpected behavior in the ARM Generic Interrupt Controller (GIC) when multiple transactions from different sources are received simultaneously and become interleaved incorrectly. This interleaving can corrupt the GIC state, leading to kernel panics and other unexpected system behavior. The problem specifically affects multi-socket configurations with more than two sockets and impacts GICv3 and GICv4 features. A software workaround has been implemented to direct read accesses properly and disable certain GICv4.x features to mitigate the issue.


How can this vulnerability impact me? :

If your system uses NVIDIA T241 server platforms with more than two interconnected T241 chips, this vulnerability can cause corruption of the Generic Interrupt Controller state. This can lead to kernel panics and unexpected system behavior, potentially causing system instability or crashes. Single or dual socket configurations are not impacted.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, implement the 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. This involves using the gic_configure_irq() function which uses the same alias region for both read and write operations to GICD_ICFGR. Additionally, avoid configurations with more than two sockets that require multi-transfer packets over the inter-socket AXI4 Stream interface between GIC instances.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart