Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: clear the dst when changing skb protocol<br /> <br /> A not-so-careful NAT46 BPF program can crash the kernel<br /> if it indiscriminately flips ingress packets from v4 to v6:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ip6_rcv_core (net/ipv6/ip6_input.c:190:20)<br /> ipv6_rcv (net/ipv6/ip6_input.c:306:8)<br /> process_backlog (net/core/dev.c:6186:4)<br /> napi_poll (net/core/dev.c:6906:9)<br /> net_rx_action (net/core/dev.c:7028:13)<br /> do_softirq (kernel/softirq.c:462:3)<br /> netif_rx (net/core/dev.c:5326:3)<br /> dev_loopback_xmit (net/core/dev.c:4015:2)<br /> ip_mc_finish_output (net/ipv4/ip_output.c:363:8)<br /> NF_HOOK (./include/linux/netfilter.h:314:9)<br /> ip_mc_output (net/ipv4/ip_output.c:400:5)<br /> dst_output (./include/net/dst.h:459:9)<br /> ip_local_out (net/ipv4/ip_output.c:130:9)<br /> ip_send_skb (net/ipv4/ip_output.c:1496:8)<br /> udp_send_skb (net/ipv4/udp.c:1040:8)<br /> udp_sendmsg (net/ipv4/udp.c:1328:10)<br /> <br /> The output interface has a 4-&gt;6 program attached at ingress.<br /> We try to loop the multicast skb back to the sending socket.<br /> Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr<br /> and changes skb-&gt;protocol to v6. We enter ip6_rcv_core which<br /> tries to use skb_dst(). But the dst is still an IPv4 one left<br /> after IPv4 mcast output.<br /> <br /> Clear the dst in all BPF helpers which change the protocol.<br /> Try to preserve metadata dsts, those may carry non-routing<br /> metadata.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: sch_sfq: reject invalid perturb period<br /> <br /> Gerrard Tai reported that SFQ perturb_period has no range check yet,<br /> and this can be used to trigger a race condition fixed in a separate patch.<br /> <br /> We want to make sure ctl-&gt;perturb_period * HZ will not overflow<br /> and is positive.<br /> <br /> <br /> tc qd add dev lo root sfq perturb -10 # negative value : error<br /> Error: sch_sfq: invalid perturb period.<br /> <br /> tc qd add dev lo root sfq perturb 1000000000 # too big : error<br /> Error: sch_sfq: invalid perturb period.<br /> <br /> tc qd add dev lo root sfq perturb 2000000 # acceptable value<br /> tc -s -d qd sh dev lo<br /> qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec<br /> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)<br /> backlog 0b 0p requeues 0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: check that raw node were preallocated before writing summary<br /> <br /> Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault<br /> injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn&amp;#39;t<br /> check return value of jffs2_prealloc_raw_node_refs and simply lets any<br /> error propagate into jffs2_sum_write_data, which eventually calls<br /> jffs2_link_node_ref in order to link the summary to an expectedly allocated<br /> node.<br /> <br /> kernel BUG at fs/jffs2/nodelist.c:592!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592<br /> Call Trace:<br /> <br /> jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]<br /> jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874<br /> jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388<br /> jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197<br /> jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362<br /> jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301<br /> generic_perform_write+0x314/0x5d0 mm/filemap.c:3856<br /> __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973<br /> generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005<br /> call_write_iter include/linux/fs.h:2265 [inline]<br /> do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735<br /> do_iter_write+0x186/0x710 fs/read_write.c:861<br /> vfs_iter_write+0x70/0xa0 fs/read_write.c:902<br /> iter_file_splice_write+0x73b/0xc90 fs/splice.c:685<br /> do_splice_from fs/splice.c:763 [inline]<br /> direct_splice_actor+0x10c/0x170 fs/splice.c:950<br /> splice_direct_to_actor+0x337/0xa10 fs/splice.c:896<br /> do_splice_direct+0x1a9/0x280 fs/splice.c:1002<br /> do_sendfile+0xb13/0x12c0 fs/read_write.c:1255<br /> __do_sys_sendfile64 fs/read_write.c:1323 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1309 [inline]<br /> __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Fix this issue by checking return value of jffs2_prealloc_raw_node_refs<br /> before calling jffs2_sum_write_data.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()<br /> <br /> ERROR INFO:<br /> <br /> CPU 25 Unable to handle kernel paging request at virtual address 0x0<br /> ...<br /> Call Trace:<br /> [] huge_pte_offset+0x3c/0x58<br /> [] hugetlb_follow_page_mask+0x74/0x438<br /> [] __get_user_pages+0xe0/0x4c8<br /> [] faultin_page_range+0x84/0x380<br /> [] madvise_vma_behavior+0x534/0xa48<br /> [] do_madvise+0x1bc/0x3e8<br /> [] sys_madvise+0x24/0x38<br /> [] do_syscall+0x78/0x98<br /> [] handle_syscall+0xb8/0x158<br /> <br /> In some cases, pmd may be NULL and rely on NULL as the return value for<br /> processing, so it is necessary to determine this situation here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: validate buffer count with offset for cloning<br /> <br /> syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt<br /> that&amp;#39;s too big:<br /> <br /> WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> lr : __do_kmalloc_node mm/slub.c:-1 [inline]<br /> lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012<br /> sp : ffff80009cfd7a90<br /> x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0<br /> x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000<br /> x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8<br /> x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff<br /> x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005<br /> x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938<br /> x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000<br /> x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)<br /> kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]<br /> io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]<br /> io_clone_buffers io_uring/rsrc.c:1178 [inline]<br /> io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287<br /> __io_uring_register io_uring/register.c:815 [inline]<br /> __do_sys_io_uring_register io_uring/register.c:926 [inline]<br /> __se_sys_io_uring_register io_uring/register.c:903 [inline]<br /> __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> which is due to offset + buffer_count being too large. The registration<br /> code checks only the total count of buffers, but given that the indexing<br /> is an array, it should also check offset + count. That can&amp;#39;t exceed<br /> IORING_MAX_REG_BUFFERS either, as there&amp;#39;s no way to reach buffers beyond<br /> that limit.<br /> <br /> There&amp;#39;s no issue with registrering a table this large, outside of the<br /> fact that it&amp;#39;s pointless to register buffers that cannot be reached, and<br /> that it can trigger this kmalloc() warning for attempting an allocation<br /> that is too large.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell_rbu: Fix list usage<br /> <br /> Pass the correct list head to list_for_each_entry*() when looping through<br /> the packet list.<br /> <br /> Without this patch, reading the packet data via sysfs will show the data<br /> incorrectly (because it starts at the wrong packet), and clearing the<br /> packet list will result in a NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()<br /> <br /> Before calling lan743x_ptp_io_event_clock_get(), the &amp;#39;channel&amp;#39; value<br /> is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).<br /> This seems correct and aligns with the PTP interrupt status register<br /> (PTP_INT_STS) specifications.<br /> <br /> However, lan743x_ptp_io_event_clock_get() writes to ptp-&gt;extts[] with<br /> only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:<br /> <br /> lan743x_ptp_io_event_clock_get(..., u8 channel,...)<br /> {<br /> ...<br /> /* Update Local timestamp */<br /> extts = &amp;ptp-&gt;extts[channel];<br /> extts-&gt;ts.tv_sec = sec;<br /> ...<br /> }<br /> <br /> To avoid an out-of-bounds write and utilize all the supported GPIO<br /> inputs, set LAN743X_PTP_N_EXTTS to 8.<br /> <br /> Detected using the static analysis tool - Svace.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer<br /> <br /> The reproduction steps:<br /> 1. create a tun interface<br /> 2. enable l2 bearer<br /> 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun<br /> <br /> tipc: Started in network mode<br /> tipc: Node identity 8af312d38a21, cluster identity 4711<br /> tipc: Enabled bearer , priority 1<br /> Oops: general protection fault<br /> KASAN: null-ptr-deref in range<br /> CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT<br /> Hardware name: QEMU Ubuntu 24.04 PC<br /> RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0<br /> <br /> the ub was in fact a struct dev.<br /> <br /> when bid != 0 &amp;&amp; skip_cnt != 0, bearer_list[bid] may be NULL or<br /> other media when other thread changes it.<br /> <br /> fix this by checking media_id.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: atmtcp: Free invalid length skb in atmtcp_c_send().<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> vcc_sendmsg() copies data passed from userspace to skb and passes<br /> it to vcc-&gt;dev-&gt;ops-&gt;send().<br /> <br /> atmtcp_c_send() accesses skb-&gt;data as struct atmtcp_hdr after<br /> checking if skb-&gt;len is 0, but it&amp;#39;s not enough.<br /> <br /> Also, when skb-&gt;len == 0, skb and sk (vcc) were leaked because<br /> dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing<br /> to revert atm_account_tx() in vcc_sendmsg(), which is expected<br /> to be done in atm_pop_raw().<br /> <br /> Let&amp;#39;s properly free skb with an invalid length in atmtcp_c_send().<br /> <br /> [0]:<br /> BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294<br /> atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294<br /> vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:727<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620<br /> __sys_sendmsg net/socket.c:2652 [inline]<br /> __do_sys_sendmsg net/socket.c:2657 [inline]<br /> __se_sys_sendmsg net/socket.c:2655 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655<br /> x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4154 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249<br /> kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579<br /> __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670<br /> alloc_skb include/linux/skbuff.h:1336 [inline]<br /> vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:727<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620<br /> __sys_sendmsg net/socket.c:2652 [inline]<br /> __do_sys_sendmsg net/socket.c:2657 [inline]<br /> __se_sys_sendmsg net/socket.c:2655 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655<br /> x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()<br /> <br /> Before the commit under the Fixes tag below, bnxt_ulp_stop() and<br /> bnxt_ulp_start() were always invoked in pairs. After that commit,<br /> the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()<br /> has been called. This may result in the RoCE driver&amp;#39;s aux driver<br /> .suspend() method being invoked twice. The 2nd bnxt_re_suspend()<br /> call will crash when it dereferences a NULL pointer:<br /> <br /> (NULL ib_device): Handle device suspend call<br /> BUG: kernel NULL pointer dereference, address: 0000000000000b78<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017<br /> Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]<br /> RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]<br /> Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00<br /> RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff<br /> RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff<br /> R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070<br /> R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bnxt_ulp_stop+0x69/0x90 [bnxt_en]<br /> bnxt_sp_task+0x678/0x920 [bnxt_en]<br /> ? __schedule+0x514/0xf50<br /> process_scheduled_works+0x9d/0x400<br /> worker_thread+0x11c/0x260<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xfe/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2b/0x40<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag<br /> is already set. This will preserve the original symmetrical<br /> bnxt_ulp_stop() and bnxt_ulp_start().<br /> <br /> Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED<br /> flag after taking the mutex to avoid any race condition. And for<br /> symmetry, only proceed in bnxt_ulp_start() if the<br /> BNXT_EN_FLAG_ULP_STOPPED is set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()<br /> <br /> The RPC container is released after being passed to r535_gsp_rpc_send().<br /> <br /> When sending the initial fragment of a large RPC and passing the<br /> caller&amp;#39;s RPC container, the container will be freed prematurely. Subsequent<br /> attempts to send remaining fragments will therefore result in a<br /> use-after-free.<br /> <br /> Allocate a temporary RPC container for holding the initial fragment of a<br /> large RPC when sending. Free the caller&amp;#39;s container when all fragments<br /> are successfully sent.<br /> <br /> [ Rebase onto Blackwell changes. - Danilo ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE<br /> <br /> Calling this packet is necessary when we switch contexts because there<br /> are various pieces of state used by userspace to synchronize between BR<br /> and BV that are persistent across submits and we need to make sure that<br /> they are in a "safe" state when switching contexts. Otherwise a<br /> userspace submission in one context could cause another context to<br /> function incorrectly and hang, effectively a denial of service (although<br /> without leaking data). This was missed during initial a7xx bringup.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/654924/