Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix IPsec cleanup over MPV device<br /> <br /> When we do mlx5e_detach_netdev() we eventually disable blocking events<br /> notifier, among those events are IPsec MPV events from IB to core.<br /> <br /> So before disabling those blocking events, make sure to also unregister<br /> the devcom device and mark all this device operations as complete,<br /> in order to prevent the other device from using invalid netdev<br /> during future devcom events which could cause the trace below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> PGD 146427067 P4D 146427067 PUD 146488067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40<br /> RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206<br /> RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00<br /> RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000<br /> R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600<br /> R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80<br /> FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x20/0x60<br /> ? page_fault_oops+0x150/0x3e0<br /> ? exc_page_fault+0x74/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core]<br /> mlx5_devcom_send_event+0x8c/0x170 [mlx5_core]<br /> blocking_event+0x17b/0x230 [mlx5_core]<br /> notifier_call_chain+0x35/0xa0<br /> blocking_notifier_call_chain+0x3d/0x60<br /> mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]<br /> mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core]<br /> mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib]<br /> mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib]<br /> ? idr_alloc_cyclic+0x50/0xb0<br /> ? __kmalloc_cache_noprof+0x167/0x340<br /> ? __kmalloc_noprof+0x1a7/0x430<br /> __mlx5_ib_add+0x34/0xd0 [mlx5_ib]<br /> mlx5r_probe+0xe9/0x310 [mlx5_ib]<br /> ? kernfs_add_one+0x107/0x150<br /> ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]<br /> auxiliary_bus_probe+0x3e/0x90<br /> really_probe+0xc5/0x3a0<br /> ? driver_probe_device+0x90/0x90<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> bus_for_each_drv+0x80/0xd0<br /> __device_attach+0xbc/0x1f0<br /> bus_probe_device+0x86/0xa0<br /> device_add+0x62d/0x830<br /> __auxiliary_device_add+0x3b/0xa0<br /> ? auxiliary_device_init+0x41/0x90<br /> add_adev+0xd1/0x150 [mlx5_core]<br /> mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core]<br /> esw_mode_change+0x6c/0xc0 [mlx5_core]<br /> mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core]<br /> devlink_nl_eswitch_set_doit+0x60/0xe0<br /> genl_family_rcv_msg_doit+0xd0/0x120<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_get_from_attrs_lock+0x170/0x170<br /> ? devlink_nl_eswitch_get_doit+0x290/0x290<br /> ? devlink_nl_pre_doit_port_optional+0x50/0x50<br /> ? genl_family_rcv_msg_dumpit+0xf0/0xf0<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1fc/0x2d0<br /> netlink_sendmsg+0x1e4/0x410<br /> __sock_sendmsg+0x38/0x60<br /> ? sockfd_lookup_light+0x12/0x60<br /> __sys_sendto+0x105/0x160<br /> ? __sys_recvmsg+0x4e/0x90<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f27bc91b13a<br /> Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: micrel: always set shared-&gt;phydev for LAN8814<br /> <br /> Currently, during the LAN8814 PTP probe shared-&gt;phydev is only set if PTP<br /> clock gets actually set, otherwise the function will return before setting<br /> it.<br /> <br /> This is an issue as shared-&gt;phydev is unconditionally being used when IRQ<br /> is being handled, especially in lan8814_gpio_process_cap and since it was<br /> not set it will cause a NULL pointer exception and crash the kernel.<br /> <br /> So, simply always set shared-&gt;phydev to avoid the NULL pointer exception.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix kernel panic on partial unmap of a GPU VA region<br /> <br /> This commit address a kernel panic issue that can happen if Userspace<br /> tries to partially unmap a GPU virtual region (aka drm_gpuva).<br /> The VM_BIND interface allows partial unmapping of a BO.<br /> <br /> Panthor driver pre-allocates memory for the new drm_gpuva structures<br /> that would be needed for the map/unmap operation, done using drm_gpuvm<br /> layer. It expected that only one new drm_gpuva would be needed on umap<br /> but a partial unmap can require 2 new drm_gpuva and that&amp;#39;s why it<br /> ended up doing a NULL pointer dereference causing a kernel panic.<br /> <br /> Following dump was seen when partial unmap was exercised.<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078<br /> Mem abort info:<br /> ESR = 0x0000000096000046<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000<br /> [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP<br /> <br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]<br /> sp : ffff800085d43970<br /> x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000<br /> x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000<br /> x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010<br /> x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c<br /> x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58<br /> x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c<br /> x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7<br /> x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001<br /> x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078<br /> Call trace:<br /> panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> op_remap_cb.isra.22+0x50/0x80<br /> __drm_gpuvm_sm_unmap+0x10c/0x1c8<br /> drm_gpuvm_sm_unmap+0x40/0x60<br /> panthor_vm_exec_op+0xb4/0x3d0 [panthor]<br /> panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]<br /> panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]<br /> drm_ioctl_kernel+0xbc/0x138<br /> drm_ioctl+0x240/0x500<br /> __arm64_sys_ioctl+0xb0/0xf8<br /> invoke_syscall+0x4c/0x110<br /> el0_svc_common.constprop.1+0x98/0xf8<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x40/0xf8<br /> el0t_64_sync_handler+0xa0/0xc8<br /> el0t_64_sync+0x174/0x178

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Account for failed debug initialization<br /> <br /> When the SCMI debug subsystem fails to initialize, the related debug root<br /> will be missing, and the underlying descriptor will be NULL.<br /> <br /> Handle this fault condition in the SCMI debug helpers that maintain<br /> metrics counters.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: dealloc commit test ctx always<br /> <br /> The damon_ctx for testing online DAMON parameters commit inputs is<br /> deallocated only when the test fails. This means memory is leaked for<br /> every successful online DAMON parameters commit. Fix the leak by always<br /> deallocating it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: catch commit test ctx alloc failure<br /> <br /> Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation".<br /> <br /> DAMON sysfs interface dynamically allocates and uses a damon_ctx object<br /> for testing if given inputs for online DAMON parameters update is valid.<br /> The object is being used without an allocation failure check, and leaked<br /> when the test succeeds. Fix the two bugs.<br /> <br /> <br /> This patch (of 2):<br /> <br /> The damon_ctx for testing online DAMON parameters commit inputs is used<br /> without its allocation failure check. This could result in an invalid<br /> memory access. Fix it by directly returning an error when the allocation<br /> failed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme<br /> <br /> Currently, damon_destroy_scheme() only cleans up the filter list but<br /> leaves ops_filter untouched, which could lead to memory leaks when a<br /> scheme is destroyed.<br /> <br /> This patch ensures both filter and ops_filter are properly freed in<br /> damon_destroy_scheme(), preventing potential memory leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: prevent poison consumption when splitting THP<br /> <br /> When performing memory error injection on a THP (Transparent Huge Page)<br /> mapped to userspace on an x86 server, the kernel panics with the following<br /> trace. The expected behavior is to terminate the affected process instead<br /> of panicking the kernel, as the x86 Machine Check code can recover from an<br /> in-userspace #MC.<br /> <br /> mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134<br /> mce: [Hardware Error]: RIP 10: {memchr_inv+0x4c/0xf0}<br /> mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db<br /> mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320<br /> mce: [Hardware Error]: Run the above through &amp;#39;mcelog --ascii&amp;#39;<br /> mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel<br /> Kernel panic - not syncing: Fatal local machine check<br /> <br /> The root cause of this panic is that handling a memory failure triggered<br /> by an in-userspace #MC necessitates splitting the THP. The splitting<br /> process employs a mechanism, implemented in<br /> try_to_map_unused_to_zeropage(), which reads the pages in the THP to<br /> identify zero-filled pages. However, reading the pages in the THP results<br /> in a second in-kernel #MC, occurring before the initial memory_failure()<br /> completes, ultimately leading to a kernel panic. See the kernel panic<br /> call trace on the two #MCs.<br /> <br /> First Machine Check occurs // [1]<br /> memory_failure() // [2]<br /> try_to_split_thp_page()<br /> split_huge_page()<br /> split_huge_page_to_list_to_order()<br /> __folio_split() // [3]<br /> remap_page()<br /> remove_migration_ptes()<br /> remove_migration_pte()<br /> try_to_map_unused_to_zeropage() // [4]<br /> memchr_inv() // [5]<br /> Second Machine Check occurs // [6]<br /> Kernel panic<br /> <br /> [1] Triggered by accessing a hardware-poisoned THP in userspace, which is<br /> typically recoverable by terminating the affected process.<br /> <br /> [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().<br /> <br /> [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().<br /> <br /> [4] Try to map the unused THP to zeropage.<br /> <br /> [5] Re-access pages in the hw-poisoned THP in the kernel.<br /> <br /> [6] Triggered in-kernel, leading to a panic kernel.<br /> <br /> In Step[2], memory_failure() sets the poisoned flag on the page in the THP<br /> by TestSetPageHWPoison() before calling try_to_split_thp_page().<br /> <br /> As suggested by David Hildenbrand, fix this panic by not accessing to the<br /> poisoned page in the THP during zeropage identification, while continuing<br /> to scan unaffected pages in the THP for possible zeropage mapping. This<br /> prevents a second in-kernel #MC that would cause kernel panic in Step[4].<br /> <br /> Thanks to Andrew Zaborowski for his initial work on fixing this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: fix lock inversion in vsock_assign_transport()<br /> <br /> Syzbot reported a potential lock inversion deadlock between<br /> vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.<br /> <br /> The issue was introduced by commit 687aa0c5581b ("vsock: Fix<br /> transport_* TOCTOU") which added vsock_register_mutex locking in<br /> vsock_assign_transport() around the transport-&gt;release() call, that can<br /> call vsock_linger(). vsock_assign_transport() can be called with sk_lock<br /> held. vsock_linger() calls sk_wait_event() that temporarily releases and<br /> re-acquires sk_lock. During this window, if another thread hold<br /> vsock_register_mutex while trying to acquire sk_lock, a circular<br /> dependency is created.<br /> <br /> Fix this by releasing vsock_register_mutex before calling<br /> transport-&gt;release() and vsock_deassign_transport(). This is safe<br /> because we don&amp;#39;t need to hold vsock_register_mutex while releasing the<br /> old transport, and we ensure the new transport won&amp;#39;t disappear by<br /> obtaining a module reference first via try_module_get().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: sh-sci: fix RSCI FIFO overrun handling<br /> <br /> The receive error handling code is shared between RSCI and all other<br /> SCIF port types, but the RSCI overrun_reg is specified as a memory<br /> offset, while for other SCIF types it is an enum value used to index<br /> into the sci_port_params-&gt;regs array, as mentioned above the<br /> sci_serial_in() function.<br /> <br /> For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call<br /> inside the sci_handle_fifo_overrun() function to index outside the<br /> bounds of the regs array, which currently has a size of 20, as specified<br /> by SCI_NR_REGS.<br /> <br /> Because of this, we end up accessing memory outside of RSCI&amp;#39;s<br /> rsci_port_params structure, which, when interpreted as a plat_sci_reg,<br /> happens to have a non-zero size, causing the following WARN when<br /> sci_serial_in() is called, as the accidental size does not match the<br /> supported register sizes.<br /> <br /> The existence of the overrun_reg needs to be checked because<br /> SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not<br /> present in the regs array.<br /> <br /> Avoid calling sci_getreg() for port types which don&amp;#39;t use standard<br /> register handling.<br /> <br /> Use the ops-&gt;read_reg() and ops-&gt;write_reg() functions to properly read<br /> and write registers for RSCI, and change the type of the status variable<br /> to accommodate the 32-bit CSR register.<br /> <br /> sci_getreg() and sci_serial_in() are also called with overrun_reg in the<br /> sci_mpxed_interrupt() interrupt handler, but that code path is not used<br /> for RSCI, as it does not have a muxed interrupt.<br /> <br /> ------------[ cut here ]------------<br /> Invalid register access<br /> WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac<br /> Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT<br /> Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)<br /> pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : sci_serial_in+0x38/0xac<br /> lr : sci_serial_in+0x38/0xac<br /> sp : ffff800080003e80<br /> x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d<br /> x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80<br /> x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000<br /> x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a<br /> x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720<br /> x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720<br /> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48<br /> x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48<br /> x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80<br /> Call trace:<br /> sci_serial_in+0x38/0xac (P)<br /> sci_handle_fifo_overrun.isra.0+0x70/0x134<br /> sci_er_interrupt+0x50/0x39c<br /> __handle_irq_event_percpu+0x48/0x140<br /> handle_irq_event+0x44/0xb0<br /> handle_fasteoi_irq+0xf4/0x1a0<br /> handle_irq_desc+0x34/0x58<br /> generic_handle_domain_irq+0x1c/0x28<br /> gic_handle_irq+0x4c/0x140<br /> call_on_irq_stack+0x30/0x48<br /> do_interrupt_handler+0x80/0x84<br /> el1_interrupt+0x34/0x68<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x6c/0x70<br /> default_idle_call+0x28/0x58 (P)<br /> do_idle+0x1f8/0x250<br /> cpu_startup_entry+0x34/0x3c<br /> rest_init+0xd8/0xe0<br /> console_on_rootfs+0x0/0x6c<br /> __primary_switched+0x88/0x90<br /> ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: Fix use-after-free in hdm_disconnect<br /> <br /> hdm_disconnect() calls most_deregister_interface(), which eventually<br /> unregisters the MOST interface device with device_unregister(iface-&gt;dev).<br /> If that drops the last reference, the device core may call release_mdev()<br /> immediately while hdm_disconnect() is still executing.<br /> <br /> The old code also freed several mdev-owned allocations in<br /> hdm_disconnect() and then performed additional put_device() calls.<br /> Depending on refcount order, this could lead to use-after-free or<br /> double-free when release_mdev() ran (or when unregister paths also<br /> performed puts).<br /> <br /> Fix by moving the frees of mdev-owned allocations into release_mdev(),<br /> so they happen exactly once when the device is truly released, and by<br /> dropping the extra put_device() calls in hdm_disconnect() that are<br /> redundant after device_unregister() and most_deregister_interface().<br /> <br /> This addresses the KASAN slab-use-after-free reported by syzbot in<br /> hdm_disconnect(). See report and stack traces in the bug link below.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()<br /> <br /> The driver allocates memory for sensor data using devm_kzalloc(), but<br /> did not check if the allocation succeeded. In case of memory allocation<br /> failure, dereferencing the NULL pointer would lead to a kernel crash.<br /> <br /> Add a NULL pointer check and return -ENOMEM to handle allocation failure<br /> properly.