Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, hsr: reject HSR frame if skb can&amp;#39;t hold tag<br /> <br /> Receiving HSR frame with insufficient space to hold HSR tag in the skb<br /> can result in a crash (kernel BUG):<br /> <br /> [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1<br /> [ 45.392559] ------------[ cut here ]------------<br /> [ 45.392912] kernel BUG at net/core/skbuff.c:211!<br /> [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)<br /> [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0<br /> <br /> <br /> <br /> [ 45.402911] Call Trace:<br /> [ 45.403105] <br /> [ 45.404470] skb_push+0xcd/0xf0<br /> [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0<br /> [ 45.406513] br_forward_finish+0x128/0x260<br /> [ 45.408483] __br_forward+0x42d/0x590<br /> [ 45.409464] maybe_deliver+0x2eb/0x420<br /> [ 45.409763] br_flood+0x174/0x4a0<br /> [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0<br /> [ 45.411618] br_handle_frame+0xac3/0x1230<br /> [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0<br /> [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0<br /> [ 45.424478] __netif_receive_skb+0x22/0x170<br /> [ 45.424806] process_backlog+0x242/0x6d0<br /> [ 45.425116] __napi_poll+0xbb/0x630<br /> [ 45.425394] net_rx_action+0x4d1/0xcc0<br /> [ 45.427613] handle_softirqs+0x1a4/0x580<br /> [ 45.427926] do_softirq+0x74/0x90<br /> [ 45.428196] <br /> <br /> This issue was found by syzkaller.<br /> <br /> The panic happens in br_dev_queue_push_xmit() once it receives a<br /> corrupted skb with ETH header already pushed in linear data. When it<br /> attempts the skb_push() call, there&amp;#39;s not enough headroom and<br /> skb_push() panics.<br /> <br /> The corrupted skb is put on the queue by HSR layer, which makes a<br /> sequence of unintended transformations when it receives a specific<br /> corrupted HSR frame (with incomplete TAG).<br /> <br /> Fix it by dropping and consuming frames that are not long enough to<br /> contain both ethernet and hsr headers.<br /> <br /> Alternative fix would be to check for enough headroom before skb_push()<br /> in br_dev_queue_push_xmit().<br /> <br /> In the reproducer, this is injected via AF_PACKET, but I don&amp;#39;t easily<br /> see why it couldn&amp;#39;t be sent over the wire from adjacent network.<br /> <br /> Further Details:<br /> <br /> In the reproducer, the following network interface chain is set up:<br /> <br /> ┌────────────────┐ ┌────────────────┐<br /> │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐<br /> └────────────────┘ └────────────────┘ │<br /> │ ┌──────┐<br /> ├─┤ hsr0 ├───┐<br /> │ └──────┘ │<br /> ┌────────────────┐ ┌────────────────┐ │ │┌────────┐<br /> │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │<br /> └────────────────┘ └────────────────┘ ┌┼ bridge │<br /> ││ │<br /> │└────────┘<br /> │<br /> ┌───────┐ │<br /> │ ... ├──────┘<br /> └───────┘<br /> <br /> To trigger the events leading up to crash, reproducer sends a corrupted<br /> HSR fr<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix stack protector issue in send_ipi_data()<br /> <br /> Function kvm_io_bus_read() is called in function send_ipi_data(), buffer<br /> size of parameter *val should be at least 8 bytes. Since some emulation<br /> functions like loongarch_ipi_readl() and kvm_eiointc_read() will write<br /> the buffer *val with 8 bytes signed extension regardless parameter len.<br /> <br /> Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR<br /> is enabled. The bug report is shown as follows:<br /> <br /> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]<br /> CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)<br /> Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000<br /> 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998<br /> 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058<br /> fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00<br /> 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e<br /> 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000<br /> 0000000000000000 0000000000000000 9000000005709968 90000000058f9000<br /> 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940<br /> 900000010001f360 0000000000000000 9000000003af3734 000000004390000c<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d<br /> ...<br /> Call Trace:<br /> [] show_stack+0x5c/0x180<br /> [] dump_stack_lvl+0x6c/0x9c<br /> [] vpanic+0x108/0x2c4<br /> [] panic+0x3c/0x40<br /> [] __stack_chk_fail+0x14/0x18<br /> [] send_ipi_data+0x190/0x1a0 [kvm]<br /> [] __kvm_io_bus_write+0xa4/0xe8 [kvm]<br /> [] kvm_io_bus_write+0x54/0x90 [kvm]<br /> [] kvm_emu_iocsr+0x180/0x310 [kvm]<br /> [] kvm_handle_gspr+0x280/0x478 [kvm]<br /> [] kvm_handle_exit+0xc0/0x130 [kvm]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix a Null pointer dereference vulnerability<br /> <br /> [Why]<br /> A null pointer dereference vulnerability exists in the AMD display driver&amp;#39;s<br /> (DC module) cleanup function dc_destruct().<br /> When display control context (dc-&gt;ctx) construction fails<br /> (due to memory allocation failure), this pointer remains NULL.<br /> During subsequent error handling when dc_destruct() is called,<br /> there&amp;#39;s no NULL check before dereferencing the perf_trace member<br /> (dc-&gt;ctx-&gt;perf_trace), causing a kernel null pointer dereference crash.<br /> <br /> [How]<br /> Check if dc-&gt;ctx is non-NULL before dereferencing.<br /> <br /> (Updated commit text and removed unnecessary error message)<br /> (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Destroy KFD debugfs after destroy KFD wq<br /> <br /> Since KFD proc content was moved to kernel debugfs, we can&amp;#39;t destroy KFD<br /> debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior<br /> to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens<br /> when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but<br /> kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line<br /> debugfs_remove_recursive(entry-&gt;proc_dentry);<br /> tries to remove /sys/kernel/debug/kfd/proc/ while<br /> /sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel<br /> NULL pointer.<br /> <br /> (cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities<br /> <br /> HUBBUB structure is not initialized on DCE hardware, so check if it is NULL<br /> to avoid null dereference while accessing amdgpu_dm_capabilities file in<br /> debugfs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid a NULL pointer dereference<br /> <br /> [WHY]<br /> Although unlikely drm_atomic_get_new_connector_state() or<br /> drm_atomic_get_old_connector_state() can return NULL.<br /> <br /> [HOW]<br /> Check returns before dereference.<br /> <br /> (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Fix SCCB present check<br /> <br /> Tracing code called by the SCLP interrupt handler contains early exits<br /> if the SCCB address associated with an interrupt is NULL. This check is<br /> performed after physical to virtual address translation.<br /> <br /> If the kernel identity mapping does not start at address zero, the<br /> resulting virtual address is never zero, so that the NULL checks won&amp;#39;t<br /> work. Subsequently this may result in incorrect accesses to the first<br /> page of the identity mapping.<br /> <br /> Fix this by introducing a function that handles the NULL case before<br /> address translation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Flush delayed SKBs while releasing RXE resources<br /> <br /> When skb packets are sent out, these skb packets still depends on<br /> the rxe resources, for example, QP, sk, when these packets are<br /> destroyed.<br /> <br /> If these rxe resources are released when the skb packets are destroyed,<br /> the call traces will appear.<br /> <br /> To avoid skb packets hang too long time in some network devices,<br /> a timestamp is added when these skb packets are created. If these<br /> skb packets hang too long time in network devices, these network<br /> devices can free these skb packets to release rxe resources.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv<br /> <br /> During the conversion to unify the calibration data management, the<br /> reference to tasdevice_priv was wrongly set to h-&gt;hda_priv instead of<br /> h-&gt;priv. This resulted in memory corruption and crashes eventually.<br /> Unfortunately it&amp;#39;s a void pointer, hence the compiler couldn&amp;#39;t know<br /> that it&amp;#39;s wrong.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a race when updating an existing write<br /> <br /> After nfs_lock_and_join_requests() tests for whether the request is<br /> still attached to the mapping, nothing prevents a call to<br /> nfs_inode_remove_request() from succeeding until we actually lock the<br /> page group.<br /> The reason is that whoever called nfs_inode_remove_request() doesn&amp;#39;t<br /> necessarily have a lock on the page group head.<br /> <br /> So in order to avoid races, let&amp;#39;s take the page group lock earlier in<br /> nfs_lock_and_join_requests(), and hold it across the removal of the<br /> request in nfs_inode_remove_request().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/futex: ensure io_futex_wait() cleans up properly on failure<br /> <br /> The io_futex_data is allocated upfront and assigned to the io_kiocb<br /> async_data field, but the request isn&amp;#39;t marked with REQ_F_ASYNC_DATA<br /> at that point. Those two should always go together, as the flag tells<br /> io_uring whether the field is valid or not.<br /> <br /> Additionally, on failure cleanup, the futex handler frees the data but<br /> does not clear -&gt;async_data. Clear the data and the flag in the error<br /> path as well.<br /> <br /> Thanks to Trend Micro Zero Day Initiative and particularly ReDress for<br /> reporting this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: prevent NULL deref in iova_to_phys<br /> <br /> The riscv_iommu_pte_fetch() function returns either NULL for<br /> unmapped/never-mapped iova, or a valid leaf pte pointer that<br /> requires no further validation.<br /> <br /> riscv_iommu_iova_to_phys() failed to handle NULL returns.<br /> Prevent null pointer dereference in<br /> riscv_iommu_iova_to_phys(), and remove the pte validation.