CVE-2023-53383

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4<br /> <br /> The T241 platform suffers from the T241-FABRIC-4 erratum which causes<br /> unexpected behavior in the GIC when multiple transactions are received<br /> simultaneously from different sources. This hardware issue impacts<br /> NVIDIA server platforms that use more than two T241 chips<br /> interconnected. Each chip has support for 320 {E}SPIs.<br /> <br /> This issue occurs when multiple packets from different GICs are<br /> incorrectly interleaved at the target chip. The erratum text below<br /> specifies exactly what can cause multiple transfer packets susceptible<br /> to interleaving and GIC state corruption. GIC state corruption can<br /> lead to a range of problems, including kernel panics, and unexpected<br /> behavior.<br /> <br /> &gt;From the erratum text:<br /> "In some cases, inter-socket AXI4 Stream packets with multiple<br /> transfers, may be interleaved by the fabric when presented to ARM<br /> Generic Interrupt Controller. GIC expects all transfers of a packet<br /> to be delivered without any interleaving.<br /> <br /> The following GICv3 commands may result in multiple transfer packets<br /> over inter-socket AXI4 Stream interface:<br /> - Register reads from GICD_I* and GICD_N*<br /> - Register writes to 64-bit GICD registers other than GICD_IROUTERn*<br /> - ITS command MOVALL<br /> <br /> Multiple commands in GICv4+ utilize multiple transfer packets,<br /> including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."<br /> <br /> This issue impacts system configurations with more than 2 sockets,<br /> that require multi-transfer packets to be sent over inter-socket<br /> AXI4 Stream interface between GIC instances on different sockets.<br /> GICv4 cannot be supported. GICv3 SW model can only be supported<br /> with the workaround. Single and Dual socket configurations are not<br /> impacted by this issue and support GICv3 and GICv4."<br /> <br /> <br /> Writing to the chip alias region of the GICD_In{E} registers except<br /> GICD_ICENABLERn has an equivalent effect as writing to the global<br /> distributor. The SPI interrupt deactivate path is not impacted by<br /> the erratum.<br /> <br /> To fix this problem, implement a workaround that ensures read accesses<br /> to the GICD_In{E} registers are directed to the chip that owns the<br /> SPI, and disable GICv4.x features. To simplify code changes, the<br /> gic_configure_irq() function uses the same alias region for both read<br /> and write operations to GICD_ICFGR.