Vulnerabilities

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

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()`<br /> <br /> The following kernel Oops was recently reported by Mesa CI:<br /> <br /> [ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588<br /> [ 800.148619] Mem abort info:<br /> [ 800.151402] ESR = 0x0000000096000005<br /> [ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 800.160444] SET = 0, FnV = 0<br /> [ 800.163488] EA = 0, S1PTW = 0<br /> [ 800.166619] FSC = 0x05: level 1 translation fault<br /> [ 800.171487] Data abort info:<br /> [ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000<br /> [ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight<br /> [ 800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1<br /> [ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d]<br /> [ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d]<br /> [ 800.267251] sp : ffffffc080003e60<br /> [ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000<br /> [ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020<br /> [ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158<br /> [ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000<br /> [ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000<br /> [ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c<br /> [ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0<br /> [ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980<br /> [ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382<br /> [ 800.341859] Call trace:<br /> [ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d]<br /> [ 800.349086] v3d_irq+0x124/0x2e0 [v3d]<br /> [ 800.352835] __handle_irq_event_percpu+0x58/0x218<br /> [ 800.357539] handle_irq_event+0x54/0xb8<br /> [ 800.361369] handle_fasteoi_irq+0xac/0x240<br /> [ 800.365458] handle_irq_desc+0x48/0x68<br /> [ 800.369200] generic_handle_domain_irq+0x24/0x38<br /> [ 800.373810] gic_handle_irq+0x48/0xd8<br /> [ 800.377464] call_on_irq_stack+0x24/0x58<br /> [ 800.381379] do_interrupt_handler+0x88/0x98<br /> [ 800.385554] el1_interrupt+0x34/0x68<br /> [ 800.389123] el1h_64_irq_handler+0x18/0x28<br /> [ 800.393211] el1h_64_irq+0x64/0x68<br /> [ 800.396603] default_idle_call+0x3c/0x168<br /> [ 800.400606] do_idle+0x1fc/0x230<br /> [ 800.403827] cpu_startup_entry+0x40/0x50<br /> [ 800.407742] rest_init+0xe4/0xf0<br /> [ 800.410962] start_kernel+0x5e8/0x790<br /> [ 800.414616] __primary_switched+0x80/0x90<br /> [ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1)<br /> [ 800.424707] ---[ end trace 0000000000000000 ]---<br /> [ 800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> This issue happens when the file descriptor is closed before the jobs<br /> submitted by it are completed. When the job completes, we update the<br /> global GPU stats and the per-fd GPU stats, which are exposed through<br /> fdinfo. If the file descriptor was closed, then the struct `v3d_file_priv`<br /> and its stats were already freed and we can&amp;#39;t update the per-fd stats.<br /> <br /> Therefore, if the file descriptor was already closed, don&amp;#39;t u<br /> ---truncated---

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/

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 ]

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.

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.

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.

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.