CVE-2022-50625

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: amba-pl011: avoid SBSA UART accessing DMACR register<br /> <br /> Chapter "B Generic UART" in "ARM Server Base System Architecture" [1]<br /> documentation describes a generic UART interface. Such generic UART<br /> does not support DMA. In current code, sbsa_uart_pops and<br /> amba_pl011_pops share the same stop_rx operation, which will invoke<br /> pl011_dma_rx_stop, leading to an access of the DMACR register. This<br /> commit adds a using_rx_dma check in pl011_dma_rx_stop to avoid the<br /> access to DMACR register for SBSA UARTs which does not support DMA.<br /> <br /> When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux<br /> SBSA PL011 driver will access PL011 DMACR register in some functions.<br /> For most real SBSA Pl011 hardware implementations, the DMACR write<br /> behaviour will be ignored. So these DMACR operations will not cause<br /> obvious problems. But for some virtual SBSA PL011 hardware, like Xen<br /> virtual SBSA PL011 (vpl011) device, the behaviour might be different.<br /> Xen vpl011 emulation will inject a data abort to guest, when guest is<br /> accessing an unimplemented UART register. As Xen VPL011 is SBSA<br /> compatible, it will not implement DMACR register. So when Linux SBSA<br /> PL011 driver access DMACR register, it will get an unhandled data abort<br /> fault and the application will get a segmentation fault:<br /> Unhandled fault at 0xffffffc00944d048<br /> Mem abort info:<br /> ESR = 0x96000000<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x00: ttbr address size fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000000<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000<br /> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13<br /> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP<br /> ...<br /> Call trace:<br /> pl011_stop_rx+0x70/0x80<br /> tty_port_shutdown+0x7c/0xb4<br /> tty_port_close+0x60/0xcc<br /> uart_close+0x34/0x8c<br /> tty_release+0x144/0x4c0<br /> __fput+0x78/0x220<br /> ____fput+0x1c/0x30<br /> task_work_run+0x88/0xc0<br /> do_notify_resume+0x8d0/0x123c<br /> el0_svc+0xa8/0xc0<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> Code: b9000083 b901f001 794038a0 8b000042 (b9000041)<br /> ---[ end trace 83dd93df15c3216f ]---<br /> note: bootlogd[132] exited with preempt_count 1<br /> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon<br /> <br /> This has been discussed in the Xen community, and we think it should fix<br /> this in Linux. See [2] for more information.<br /> <br /> [1] https://developer.arm.com/documentation/den0094/c/?lang=en<br /> [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html