Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix dropping valid root bus resources with .end = zero<br /> <br /> On r8a7791/koelsch:<br /> <br /> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xc3a34e00 (size 64):<br /> comm "swapper/0", pid 1, jiffies 4294937460 (age 199.080s)<br /> hex dump (first 32 bytes):<br /> b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00 .]...]..........<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0xf0/0x140<br /> [] resource_list_create_entry+0x18/0x38<br /> [] pci_add_resource_offset+0x20/0x68<br /> [] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390<br /> <br /> When coalescing two resources for a contiguous aperture, the second<br /> resource is enlarged to cover the full contiguous range, while the first<br /> resource is marked invalid. This invalidation is done by clearing the<br /> flags, start, and end members.<br /> <br /> When adding the initial resources to the bus later, invalid resources are<br /> skipped. Unfortunately, the check for an invalid resource considers only<br /> the end member, causing false positives.<br /> <br /> E.g. on r8a7791/koelsch, root bus resource 0 ("bus 00") is skipped, and no<br /> longer registered with pci_bus_insert_busn_res() (causing the memory leak),<br /> nor printed:<br /> <br /> pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:<br /> pci-rcar-gen2 ee090000.pci: MEM 0x00ee080000..0x00ee08ffff -&gt; 0x00ee080000<br /> pci-rcar-gen2 ee090000.pci: PCI: revision 11<br /> pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00<br /> -pci_bus 0000:00: root bus resource [bus 00]<br /> pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]<br /> <br /> Fix this by only skipping resources where all of the flags, start, and end<br /> members are zero.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Prevent RT livelock in itimer_delete()<br /> <br /> itimer_delete() has a retry loop when the timer is concurrently expired. On<br /> non-RT kernels this just spin-waits until the timer callback has completed,<br /> except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORK<br /> enabled.<br /> <br /> In that case and on RT kernels the existing task could live lock when<br /> preempting the task which does the timer delivery.<br /> <br /> Replace spin_unlock() with an invocation of timer_wait_running() to handle<br /> it the same way as the other retry loops in the posix timer code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix potential kgd_mem UAFs<br /> <br /> kgd_mem pointers returned by kfd_process_device_translate_handle are<br /> only guaranteed to be valid while p-&gt;mutex is held. As soon as the mutex<br /> is unlocked, another thread can free the BO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()<br /> <br /> During NVMeTCP Authentication a controller can trigger a kernel<br /> oops by specifying the 8192 bit Diffie Hellman group and passing<br /> a correctly sized, but zeroed Diffie Hellamn value.<br /> mpi_cmp_ui() was detecting this if the second parameter was 0,<br /> but 1 is passed from dh_is_pubkey_valid(). This causes the null<br /> pointer u-&gt;d to be dereferenced towards the end of mpi_cmp_ui()

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Fix slab-out-of-bounds in ses_enclosure_data_process()<br /> <br /> A fix for:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]<br /> Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271<br /> <br /> Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we<br /> expect the size to be sanitized before first access to addl_desc_ptr[1].<br /> Make sure we don&amp;#39;t walk beyond end of page.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()<br /> <br /> During unmount process of nilfs2, nothing holds nilfs_root structure after<br /> nilfs2 detaches its writer in nilfs_detach_log_writer(). However, since<br /> nilfs_evict_inode() uses nilfs_root for some cleanup operations, it may<br /> cause use-after-free read if inodes are left in "garbage_list" and<br /> released by nilfs_dispose_list() at the end of nilfs_detach_log_writer().<br /> <br /> Fix this issue by modifying nilfs_evict_inode() to only clear inode<br /> without additional metadata changes that use nilfs_root if the file system<br /> is degraded to read-only or the writer is detached.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: populate subvp cmd info only for the top pipe<br /> <br /> [Why]<br /> System restart observed while changing the display resolution<br /> to 8k with extended mode. Sytem restart was caused by a page fault.<br /> <br /> [How]<br /> When the driver populates subvp info it did it for both the pipes using<br /> vblank which caused an outof bounds array access causing the page fault.<br /> added checks to allow the top pipe only to fix this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()<br /> <br /> Smatch detected this potential error pointer dereference<br /> clk_wzrd_register_divider(). If devm_clk_hw_register() fails then<br /> it sets "hw" to an error pointer and then dereferences it on the<br /> next line. Return the error directly instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: fix memory leak in mwifiex_histogram_read()<br /> <br /> Always free the zeroed page on return from &amp;#39;mwifiex_histogram_read()&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register()<br /> <br /> When a file descriptor of pppol2tp socket is passed as file descriptor<br /> of UDP socket, a recursive deadlock occurs in l2tp_tunnel_register().<br /> This situation is reproduced by the following program:<br /> <br /> int main(void)<br /> {<br /> int sock;<br /> struct sockaddr_pppol2tp addr;<br /> <br /> sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);<br /> if (sock

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: IOMMUFD_DESTROY should not increase the refcount<br /> <br /> syzkaller found a race where IOMMUFD_DESTROY increments the refcount:<br /> <br /> obj = iommufd_get_object(ucmd-&gt;ictx, cmd-&gt;id, IOMMUFD_OBJ_ANY);<br /> if (IS_ERR(obj))<br /> return PTR_ERR(obj);<br /> iommufd_ref_to_users(obj);<br /> /* See iommufd_ref_to_users() */<br /> if (!iommufd_object_destroy_user(ucmd-&gt;ictx, obj))<br /> <br /> As part of the sequence to join the two existing primitives together.<br /> <br /> Allowing the refcount the be elevated without holding the destroy_rwsem<br /> violates the assumption that all temporary refcount elevations are<br /> protected by destroy_rwsem. Racing IOMMUFD_DESTROY with<br /> iommufd_object_destroy_user() will cause spurious failures:<br /> <br /> WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478<br /> Modules linked in:<br /> CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023<br /> RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477<br /> Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41<br /> RSP: 0018:ffffc90003067e08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff<br /> RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500<br /> R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88<br /> R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe<br /> FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline]<br /> iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813<br /> iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x84/0xc0 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The solution is to not increment the refcount on the IOMMUFD_DESTROY path<br /> at all. Instead use the xa_lock to serialize everything. The refcount<br /> check == 1 and xa_erase can be done under a single critical region. This<br /> avoids the need for any refcount incrementing.<br /> <br /> It has the downside that if userspace races destroy with other operations<br /> it will get an EBUSY instead of waiting, but this is kind of racing is<br /> already dangerous.