Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Fix memory leak in rsi_coex_attach()<br /> <br /> The coex_cb needs to be freed when rsi_create_kthread() failed in<br /> rsi_coex_attach().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: hugetlb: fix UAF in hugetlb_handle_userfault<br /> <br /> The vma_lock and hugetlb_fault_mutex are dropped before handling userfault<br /> and reacquire them again after handle_userfault(), but reacquire the<br /> vma_lock could lead to UAF[1,2] due to the following race,<br /> <br /> hugetlb_fault<br /> hugetlb_no_page<br /> /*unlock vma_lock */<br /> hugetlb_handle_userfault<br /> handle_userfault<br /> /* unlock mm-&gt;mmap_lock*/<br /> vm_mmap_pgoff<br /> do_mmap<br /> mmap_region<br /> munmap_vma_range<br /> /* clean old vma */<br /> /* lock vma_lock again

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Avoid READ_ONCE() in read_instrumented_memory()<br /> <br /> Haibo Li reported:<br /> <br /> | Unable to handle kernel paging request at virtual address<br /> | ffffff802a0d8d7171<br /> | Mem abort info:o:<br /> | ESR = 0x9600002121<br /> | EC = 0x25: DABT (current EL), IL = 32 bitsts<br /> | SET = 0, FnV = 0 0<br /> | EA = 0, S1PTW = 0 0<br /> | FSC = 0x21: alignment fault<br /> | Data abort info:o:<br /> | ISV = 0, ISS = 0x0000002121<br /> | CM = 0, WnR = 0 0<br /> | swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000<br /> | [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003,<br /> | pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707<br /> | Internal error: Oops: 96000021 [#1] PREEMPT SMP<br /> | Modules linked in:<br /> | CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted<br /> | 5.15.78-android13-8-g63561175bbda-dirty #1<br /> | ...<br /> | pc : kcsan_setup_watchpoint+0x26c/0x6bc<br /> | lr : kcsan_setup_watchpoint+0x88/0x6bc<br /> | sp : ffffffc00ab4b7f0<br /> | x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001<br /> | x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80<br /> | x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71<br /> | x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060<br /> | x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000<br /> | x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0<br /> | x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8<br /> | x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70<br /> | x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000<br /> | Call trace:<br /> | kcsan_setup_watchpoint+0x26c/0x6bc<br /> | __tsan_read2+0x1f0/0x234<br /> | inflate_fast+0x498/0x750<br /> | zlib_inflate+0x1304/0x2384<br /> | __gunzip+0x3a0/0x45c<br /> | gunzip+0x20/0x30<br /> | unpack_to_rootfs+0x2a8/0x3fc<br /> | do_populate_rootfs+0xe8/0x11c<br /> | async_run_entry_fn+0x58/0x1bc<br /> | process_one_work+0x3ec/0x738<br /> | worker_thread+0x4c4/0x838<br /> | kthread+0x20c/0x258<br /> | ret_from_fork+0x10/0x20<br /> | Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) )<br /> | ---[ end trace 613a943cb0a572b6 ]-----<br /> <br /> The reason for this is that on certain arm64 configuration since<br /> e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when<br /> CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire<br /> instruction which cannot be used on unaligned addresses.<br /> <br /> Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply<br /> forcing the compiler to do the required access by casting to the<br /> appropriate volatile type. In terms of generated code this currently<br /> only affects architectures that do not use the default READ_ONCE()<br /> implementation.<br /> <br /> The only downside is that we are not guaranteed atomicity of the access<br /> itself, although on most architectures a plain load up to machine word<br /> size should still be atomic (a fact the default READ_ONCE() still relies<br /> on itself).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Free released resource after coalescing<br /> <br /> release_resource() doesn&amp;#39;t actually free the resource or resource list<br /> entry so free the resource list entry to avoid a leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe<br /> <br /> wkup_m3_ipc_get() takes refcount, which should be freed by<br /> wkup_m3_ipc_put(). Add missing refcount release in the error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: vector: Fix memory leak in vector_config<br /> <br /> If the return value of the uml_parse_vector_ifspec function is NULL,<br /> we should call kfree(params) to prevent memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio-ap: fix memory leak in vfio_ap device driver<br /> <br /> The device release callback function invoked to release the matrix device<br /> uses the dev_get_drvdata(device *dev) function to retrieve the<br /> pointer to the vfio_matrix_dev object in order to free its storage. The<br /> problem is, this object is not stored as drvdata with the device; since the<br /> kfree function will accept a NULL pointer, the memory for the<br /> vfio_matrix_dev object is never freed.<br /> <br /> Since the device being released is contained within the vfio_matrix_dev<br /> object, the container_of macro will be used to retrieve its pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: verity-loadpin: Only trust verity targets with enforcement<br /> <br /> Verity targets can be configured to ignore corrupted data blocks.<br /> LoadPin must only trust verity targets that are configured to<br /> perform some kind of enforcement when data corruption is detected,<br /> like returning an error, restarting the system or triggering a<br /> panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix potential memory leak in ext4_fc_record_modified_inode()<br /> <br /> As krealloc may return NULL, in this case &amp;#39;state-&gt;fc_modified_inodes&amp;#39;<br /> may not be freed by krealloc, but &amp;#39;state-&gt;fc_modified_inodes&amp;#39; already<br /> set NULL. Then will lead to &amp;#39;state-&gt;fc_modified_inodes&amp;#39; memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: prevent integer overflow in dfl_feature_ioctl_set_irq()<br /> <br /> The "hdr.count * sizeof(s32)" multiplication can overflow on 32 bit<br /> systems leading to memory corruption. Use array_size() to fix that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netsec: fix error handling in netsec_register_mdio()<br /> <br /> If phy_device_register() fails, phy_device_free() need be called to<br /> put refcount, so memory of phy device and device name can be freed<br /> in callback function.<br /> <br /> If get_phy_device() fails, mdiobus_unregister() need be called,<br /> or it will cause warning in mdiobus_free() and kobject is leaked.

*** 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