Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Fix memory accounting leak.<br /> <br /> Matt Dowling reported a weird UDP memory usage issue.<br /> <br /> Under normal operation, the UDP memory usage reported in /proc/net/sockstat<br /> remains close to zero. However, it occasionally spiked to 524,288 pages<br /> and never dropped. Moreover, the value doubled when the application was<br /> terminated. Finally, it caused intermittent packet drops.<br /> <br /> We can reproduce the issue with the script below [0]:<br /> <br /> 1. /proc/net/sockstat reports 0 pages<br /> <br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 1 mem 0<br /> <br /> 2. Run the script till the report reaches 524,288<br /> <br /> # python3 test.py &amp; sleep 5<br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 3 mem 524288 &gt; PAGE_SHIFT<br /> <br /> 3. Kill the socket and confirm the number never drops<br /> <br /> # pkill python3 &amp;&amp; sleep 5<br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 1 mem 524288<br /> <br /> 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()<br /> <br /> # python3 test.py &amp; sleep 1 &amp;&amp; pkill python3<br /> <br /> 5. The number doubles<br /> <br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 1 mem 1048577<br /> <br /> The application set INT_MAX to SO_RCVBUF, which triggered an integer<br /> overflow in udp_rmem_release().<br /> <br /> When a socket is close()d, udp_destruct_common() purges its receive<br /> queue and sums up skb-&gt;truesize in the queue. This total is calculated<br /> and stored in a local unsigned integer variable.<br /> <br /> The total size is then passed to udp_rmem_release() to adjust memory<br /> accounting. However, because the function takes a signed integer<br /> argument, the total size can wrap around, causing an overflow.<br /> <br /> Then, the released amount is calculated as follows:<br /> <br /> 1) Add size to sk-&gt;sk_forward_alloc.<br /> 2) Round down sk-&gt;sk_forward_alloc to the nearest lower multiple of<br /> PAGE_SIZE and assign it to amount.<br /> 3) Subtract amount from sk-&gt;sk_forward_alloc.<br /> 4) Pass amount &gt;&gt; PAGE_SHIFT to __sk_mem_reduce_allocated().<br /> <br /> When the issue occurred, the total in udp_destruct_common() was 2147484480<br /> (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().<br /> <br /> At 1) sk-&gt;sk_forward_alloc is changed from 3264 to -2147479552, and<br /> 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don&amp;#39;t<br /> see a warning in inet_sock_destruct(). However, udp_memory_allocated<br /> ends up doubling at 4).<br /> <br /> Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for<br /> memory_allocated"), memory usage no longer doubles immediately after<br /> a socket is close()d because __sk_mem_reduce_allocated() caches the<br /> amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP<br /> socket receives a packet, the subtraction takes effect, causing UDP<br /> memory usage to double.<br /> <br /> This issue makes further memory allocation fail once the socket&amp;#39;s<br /> sk-&gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet<br /> drops.<br /> <br /> To prevent this issue, let&amp;#39;s use unsigned int for the calculation and<br /> call sk_forward_alloc_add() only once for the small delta.<br /> <br /> Note that first_packet_length() also potentially has the same problem.<br /> <br /> [0]:<br /> from socket import *<br /> <br /> SO_RCVBUFFORCE = 33<br /> INT_MAX = (2 ** 31) - 1<br /> <br /> s = socket(AF_INET, SOCK_DGRAM)<br /> s.bind((&amp;#39;&amp;#39;, 0))<br /> s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)<br /> <br /> c = socket(AF_INET, SOCK_DGRAM)<br /> c.connect(s.getsockname())<br /> <br /> data = b&amp;#39;a&amp;#39; * 100<br /> <br /> while True:<br /> c.send(data)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Fix multiple wraparounds of sk-&gt;sk_rmem_alloc.<br /> <br /> __udp_enqueue_schedule_skb() has the following condition:<br /> <br /> if (atomic_read(&amp;sk-&gt;sk_rmem_alloc) &gt; sk-&gt;sk_rcvbuf)<br /> goto drop;<br /> <br /> sk-&gt;sk_rcvbuf is initialised by net.core.rmem_default and later can<br /> be configured by SO_RCVBUF, which is limited by net.core.rmem_max,<br /> or SO_RCVBUFFORCE.<br /> <br /> If we set INT_MAX to sk-&gt;sk_rcvbuf, the condition is always false<br /> as sk-&gt;sk_rmem_alloc is also signed int.<br /> <br /> Then, the size of the incoming skb is added to sk-&gt;sk_rmem_alloc<br /> unconditionally.<br /> <br /> This results in integer overflow (possibly multiple times) on<br /> sk-&gt;sk_rmem_alloc and allows a single socket to have skb up to<br /> net.core.udp_mem[1].<br /> <br /> For example, if we set a large value to udp_mem[1] and INT_MAX to<br /> sk-&gt;sk_rcvbuf and flood packets to the socket, we can see multiple<br /> overflows:<br /> <br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 3 mem 7956736 min(size + (unsigned int)sk-&gt;sk_rcvbuf, INT_MAX))<br /> goto uncharge_drop;<br /> <br /> but we do not want to add the expensive atomic_add_return() back just<br /> for the corner case.<br /> <br /> Casting rmem to unsigned int prevents multiple wraparounds, but we still<br /> allow a single wraparound.<br /> <br /> # cat /proc/net/sockstat | grep UDP:<br /> UDP: inuse 3 mem 524288 &gt; 12<br /> <br /> # ss -uam<br /> State Recv-Q ...<br /> UNCONN -2147482816 ... truesize<br /> only when rcvbuf is large enough to lower the overflow possibility.<br /> <br /> Note that we still have a small chance to see overflow if multiple skbs<br /> to the same socket are processed on different core at the same time and<br /> each size does not exceed the limit but the total size does.<br /> <br /> Note also that we must ignore skb-&gt;truesize for a small buffer as<br /> explained in commit 363dc73acacb ("udp: be less conservative with<br /> sock rmem accounting").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: Prevent parser TCAM memory corruption<br /> <br /> Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM<br /> information, from concurrent modifications.<br /> <br /> Both the TCAM and SRAM tables are indirectly accessed by configuring<br /> an index register that selects the row to read or write to. This means<br /> that operations must be atomic in order to, e.g., avoid spreading<br /> writes across multiple rows. Since the shadow SRAM array is used to<br /> find free rows in the hardware table, it must also be protected in<br /> order to avoid TOCTOU errors where multiple cores allocate the same<br /> row.<br /> <br /> This issue was detected in a situation where `mvpp2_set_rx_mode()` ran<br /> concurrently on two CPUs. In this particular case the<br /> MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the<br /> classifier unit to drop all incoming unicast - indicated by the<br /> `rx_classifier_drops` counter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Fix qid report in airoha_tc_get_htb_get_leaf_queue()<br /> <br /> Fix the following kernel warning deleting HTB offloaded leafs and/or root<br /> HTB qdisc in airoha_eth driver properly reporting qid in<br /> airoha_tc_get_htb_get_leaf_queue routine.<br /> <br /> $tc qdisc replace dev eth1 root handle 10: htb offload<br /> $tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit<br /> $tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \<br /> quanta 1514 3028 4542 6056 7570 9084 10598 12112<br /> $tc qdisc del dev eth1 root<br /> <br /> [ 55.827864] ------------[ cut here ]------------<br /> [ 55.832493] WARNING: CPU: 3 PID: 2678 at 0xffffffc0798695a4<br /> [ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: G O 6.6.71 #0<br /> [ 55.963557] Hardware name: Airoha AN7581 Evaluation Board (DT)<br /> [ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 55.976344] pc : 0xffffffc0798695a4<br /> [ 55.979851] lr : 0xffffffc079869a20<br /> [ 55.983358] sp : ffffffc0850536a0<br /> [ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001<br /> [ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800<br /> [ 56.000935] x23: 0000000000000001 x22: 0000000000000000 x21: ffffff8008b19000<br /> [ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 0000000000000000<br /> [ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000<br /> [ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001<br /> [ 56.029478] x11: ffffffc081471008 x10: ffffffc081575a98 x9 : 0000000000000000<br /> [ 56.036614] x8 : ffffffc08167fd40 x7 : ffffffc08069e104 x6 : ffffff8007f86000<br /> [ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000<br /> [ 56.058020] Call trace:<br /> [ 56.060459] 0xffffffc0798695a4<br /> [ 56.063618] 0xffffffc079869a20<br /> [ 56.066777] __qdisc_destroy+0x40/0xa0<br /> [ 56.070528] qdisc_put+0x54/0x6c<br /> [ 56.073748] qdisc_graft+0x41c/0x648<br /> [ 56.077324] tc_get_qdisc+0x168/0x2f8<br /> [ 56.080978] rtnetlink_rcv_msg+0x230/0x330<br /> [ 56.085076] netlink_rcv_skb+0x5c/0x128<br /> [ 56.088913] rtnetlink_rcv+0x14/0x1c<br /> [ 56.092490] netlink_unicast+0x1e0/0x2c8<br /> [ 56.096413] netlink_sendmsg+0x198/0x3c8<br /> [ 56.100337] ____sys_sendmsg+0x1c4/0x274<br /> [ 56.104261] ___sys_sendmsg+0x7c/0xc0<br /> [ 56.107924] __sys_sendmsg+0x44/0x98<br /> [ 56.111492] __arm64_sys_sendmsg+0x20/0x28<br /> [ 56.115580] invoke_syscall.constprop.0+0x58/0xfc<br /> [ 56.120285] do_el0_svc+0x3c/0xbc<br /> [ 56.123592] el0_svc+0x18/0x4c<br /> [ 56.126647] el0t_64_sync_handler+0x118/0x124<br /> [ 56.131005] el0t_64_sync+0x150/0x154<br /> [ 56.134660] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add mutual exclusion in proc_sctp_do_udp_port()<br /> <br /> We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()<br /> or risk a crash as syzbot reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]<br /> CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653<br /> Call Trace:<br /> <br /> udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181<br /> sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930<br /> proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553<br /> proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601<br /> iter_file_splice_write+0x91c/0x1150 fs/splice.c:738<br /> do_splice_from fs/splice.c:935 [inline]<br /> direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158<br /> splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102<br /> do_splice_direct_actor fs/splice.c:1201 [inline]<br /> do_splice_direct+0x174/0x240 fs/splice.c:1227<br /> do_sendfile+0xafd/0xe50 fs/read_write.c:1368<br /> __do_sys_sendfile64 fs/read_write.c:1429 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1415 [inline]<br /> __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_tunnel: fix geneve_opt type confusion addition<br /> <br /> When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the<br /> parsing logic should place every geneve_opt structure one by one<br /> compactly. Hence, when deciding the next geneve_opt position, the<br /> pointer addition should be in units of char *.<br /> <br /> However, the current implementation erroneously does type conversion<br /> before the addition, which will lead to heap out-of-bounds write.<br /> <br /> [ 6.989857] ==================================================================<br /> [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70<br /> [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178<br /> [ 6.991162]<br /> [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1<br /> [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 6.992281] Call Trace:<br /> [ 6.992423] <br /> [ 6.992586] dump_stack_lvl+0x44/0x5c<br /> [ 6.992801] print_report+0x184/0x4be<br /> [ 6.993790] kasan_report+0xc5/0x100<br /> [ 6.994252] kasan_check_range+0xf3/0x1a0<br /> [ 6.994486] memcpy+0x38/0x60<br /> [ 6.994692] nft_tunnel_obj_init+0x977/0xa70<br /> [ 6.995677] nft_obj_init+0x10c/0x1b0<br /> [ 6.995891] nf_tables_newobj+0x585/0x950<br /> [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020<br /> [ 6.998997] nfnetlink_rcv+0x1df/0x220<br /> [ 6.999537] netlink_unicast+0x395/0x530<br /> [ 7.000771] netlink_sendmsg+0x3d0/0x6d0<br /> [ 7.001462] __sock_sendmsg+0x99/0xa0<br /> [ 7.001707] ____sys_sendmsg+0x409/0x450<br /> [ 7.002391] ___sys_sendmsg+0xfd/0x170<br /> [ 7.003145] __sys_sendmsg+0xea/0x170<br /> [ 7.004359] do_syscall_64+0x5e/0x90<br /> [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 7.006127] RIP: 0033:0x7ec756d4e407<br /> [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf<br /> [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e<br /> [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407<br /> [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003<br /> [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000<br /> [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8<br /> <br /> Fix this bug with correct pointer addition and conversion in parse<br /> and dump code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets<br /> <br /> When calling netlbl_conn_setattr(), addr-&gt;sa_family is used<br /> to determine the function behavior. If sk is an IPv4 socket,<br /> but the connect function is called with an IPv6 address,<br /> the function calipso_sock_setattr() is triggered.<br /> Inside this function, the following code is executed:<br /> <br /> sk_fullsock(__sk) ? inet_sk(__sk)-&gt;pinet6 : NULL;<br /> <br /> Since sk is an IPv4 socket, pinet6 is NULL, leading to a<br /> null pointer dereference.<br /> <br /> This patch fixes the issue by checking if inet6_sk(sk)<br /> returns a NULL pointer before accessing pinet6.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes/x86: Harden uretprobe syscall trampoline check<br /> <br /> Jann reported a possible issue when trampoline_check_ip returns<br /> address near the bottom of the address space that is allowed to<br /> call into the syscall if uretprobes are not set up:<br /> <br /> https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf<br /> <br /> Though the mmap minimum address restrictions will typically prevent<br /> creating mappings there, let&amp;#39;s make sure uretprobe syscall checks<br /> for that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/microcode/AMD: Fix __apply_microcode_amd()&amp;#39;s return value<br /> <br /> When verify_sha256_digest() fails, __apply_microcode_amd() should propagate<br /> the failure by returning false (and not -1 which is promoted to true).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Don&amp;#39;t override subprog&amp;#39;s return value<br /> <br /> The verifier test `calls: div by 0 in subprog` triggers a panic at the<br /> ld.bu instruction. The ld.bu insn is trying to load byte from memory<br /> address returned by the subprog. The subprog actually set the correct<br /> address at the a5 register (dedicated register for BPF return values).<br /> But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values")<br /> we also sign extended a5 to the a0 register (return value in LoongArch).<br /> For function call insn, we later propagate the a0 register back to a5<br /> register. This is right for native calls but wrong for bpf2bpf calls<br /> which expect zero-extended return value in a5 register. So only move a0<br /> to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Increase ARCH_DMA_MINALIGN up to 16<br /> <br /> ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices<br /> (such as APBDMA) require 16 bytes alignment. When the data buffer length<br /> is too small, the hardware may make an error writing cacheline. Thus, it<br /> is dangerous to allocate a small memory buffer for DMA. It&amp;#39;s always safe<br /> to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc()<br /> need small memory objects). Therefore, just increase it to 16.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet:fix NPE during rx_complete<br /> <br /> Missing usbnet_going_away Check in Critical Path.<br /> The usb_submit_urb function lacks a usbnet_going_away<br /> validation, whereas __usbnet_queue_skb includes this check.<br /> <br /> This inconsistency creates a race condition where:<br /> A URB request may succeed, but the corresponding SKB data<br /> fails to be queued.<br /> <br /> Subsequent processes:<br /> (e.g., rx_complete → defer_bh → __skb_unlink(skb, list))<br /> attempt to access skb-&gt;next, triggering a NULL pointer<br /> dereference (Kernel Panic).