Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: tighten UMEM headroom validation to account for tailroom and min frame<br /> <br /> The current headroom validation in xdp_umem_reg() could leave us with<br /> insufficient space dedicated to even receive minimum-sized ethernet<br /> frame. Furthermore if multi-buffer would come to play then<br /> skb_shared_info stored at the end of XSK frame would be corrupted.<br /> <br /> HW typically works with 128-aligned sizes so let us provide this value<br /> as bare minimum.<br /> <br /> Multi-buffer setting is known later in the configuration process so<br /> besides accounting for 128 bytes, let us also take care of tailroom space<br /> upfront.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_key: zero aligned sockaddr tail in PF_KEY exports<br /> <br /> PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr<br /> payload space, so IPv6 addresses occupy 32 bytes on the wire. However,<br /> `pfkey_sockaddr_fill()` initializes only the first 28 bytes of<br /> `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.<br /> <br /> Not every PF_KEY message is affected. The state and policy dump builders<br /> already zero the whole message buffer before filling the sockaddr<br /> payloads. Keep the fix to the export paths that still append aligned<br /> sockaddr payloads with plain `skb_put()`:<br /> <br /> - `SADB_ACQUIRE`<br /> - `SADB_X_NAT_T_NEW_MAPPING`<br /> - `SADB_X_MIGRATE`<br /> <br /> Fix those paths by clearing only the aligned sockaddr tail after<br /> `pfkey_sockaddr_fill()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Drop large packets with UDP encap<br /> <br /> syzbot reported a WARN on my patch series [1]. The actual issue is an<br /> overflow of 16-bit UDP length field, and it exists in the upstream code.<br /> My series added a debug WARN with an overflow check that exposed the<br /> issue, that&amp;#39;s why syzbot tripped on my patches, rather than on upstream<br /> code.<br /> <br /> syzbot&amp;#39;s repro:<br /> <br /> r0 = socket$pppl2tp(0x18, 0x1, 0x1)<br /> r1 = socket$inet6_udp(0xa, 0x2, 0x0)<br /> connect$inet6(r1, &amp;(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)<br /> connect$pppl2tp(r0, &amp;(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={&amp;#39;\x00&amp;#39;, &amp;#39;\xff\xff&amp;#39;, @empty}}}}, 0x32)<br /> writev(r0, &amp;(0x7f0000000080)=[{&amp;(0x7f0000000000)="ee", 0x34000}], 0x1)<br /> <br /> It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP<br /> encapsulation, and l2tp_xmit_core doesn&amp;#39;t check for overflows when it<br /> assigns the UDP length field. The value gets trimmed to 16 bites.<br /> <br /> Add an overflow check that drops oversized packets and avoids sending<br /> packets with trimmed UDP length to the wire.<br /> <br /> syzbot&amp;#39;s stack trace (with my patch applied):<br /> <br /> len &gt;= 65536u<br /> WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957<br /> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957<br /> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]<br /> RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]<br /> RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327<br /> Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f<br /> RSP: 0018:ffffc90003d67878 EFLAGS: 00010293<br /> RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000<br /> RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff<br /> RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004<br /> R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900<br /> R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000<br /> FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> sock_write_iter+0x503/0x550 net/socket.c:1195<br /> do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1<br /> vfs_writev+0x33c/0x990 fs/read_write.c:1059<br /> do_writev+0x154/0x2e0 fs/read_write.c:1105<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f636479c629<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014<br /> RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629<br /> RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003<br /> RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0<br /> <br /> <br /> [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+<br /> <br /> Fix the field masks to match the hardware layout documented in<br /> downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).<br /> <br /> Notably this fixes a WARN I was seeing when I tried to send "stop"<br /> to the MPSS remoteproc while IPA was up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: leave space for null terminators on property_entry<br /> <br /> Lists of struct property_entry are supposed to be terminated with an<br /> empty property, this driver currently seems to be allocating exactly the<br /> amount of entry used.<br /> <br /> Change the struct definition to leave an extra element for all<br /> property_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator<br /> <br /> When batching multiple NFLOG messages (inst-&gt;qlen &gt; 1), __nfulnl_send()<br /> appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via<br /> nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put()<br /> helper only zeroes alignment padding after the payload, not the payload<br /> itself, so four bytes of stale kernel heap data are leaked to userspace<br /> in the NLMSG_DONE message body.<br /> <br /> Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes<br /> the nfgenmsg payload via nfnl_fill_hdr(), consistent with how<br /> __build_packet_message() already constructs NFULNL_MSG_PACKET headers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix NULL deref in ip_vs_add_service error path<br /> <br /> When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local<br /> variable sched is set to NULL. If ip_vs_start_estimator() subsequently<br /> fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)<br /> with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL<br /> check (because svc-&gt;scheduler was set by the successful bind) but then<br /> dereferences the NULL sched parameter at sched-&gt;done_service, causing a<br /> kernel panic at offset 0x30 from NULL.<br /> <br /> Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)<br /> Call Trace:<br /> <br /> ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)<br /> do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)<br /> nf_setsockopt (net/netfilter/nf_sockopt.c:102)<br /> [..]<br /> <br /> Fix by simply not clearing the local sched variable after a successful<br /> bind. ip_vs_unbind_scheduler() already detects whether a scheduler is<br /> installed via svc-&gt;scheduler, and keeping sched non-NULL ensures the<br /> error path passes the correct pointer to both ip_vs_unbind_scheduler()<br /> and ip_vs_scheduler_put().<br /> <br /> While the bug is older, the problem popups in more recent kernels (6.2),<br /> when the new error path is taken after the ip_vs_start_estimator() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Disable all pin interrupts during probe<br /> <br /> A chip being probed may have the interrupt-on-change feature enabled on<br /> some of its pins, for example after a reboot. This can cause the chip to<br /> generate interrupts for pins that don&amp;#39;t have a registered nested handler,<br /> which leads to a kernel crash such as below:<br /> <br /> [ 7.928897] Unable to handle kernel read from unreadable memory at virtual address 00000000000000ac<br /> [ 7.932314] Mem abort info:<br /> [ 7.935081] ESR = 0x0000000096000004<br /> [ 7.938808] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 7.944094] SET = 0, FnV = 0<br /> [ 7.947127] EA = 0, S1PTW = 0<br /> [ 7.950247] FSC = 0x04: level 0 translation fault<br /> [ 7.955101] Data abort info:<br /> [ 7.957961] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 7.963421] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 7.968447] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 7.973734] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000089b7000<br /> [ 7.980148] [00000000000000ac] pgd=0000000000000000, p4d=0000000000000000<br /> [ 7.986913] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 7.992545] Modules linked in:<br /> [ 8.073678] CPU: 0 UID: 0 PID: 81 Comm: irq/18-4-0025 Not tainted 7.0.0-rc6-gd2b5a1f931c8-dirty #199<br /> [ 8.073689] Hardware name: Khadas VIM3 (DT)<br /> [ 8.073692] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 8.094639] pc : _raw_spin_lock_irq+0x40/0x80<br /> [ 8.098970] lr : handle_nested_irq+0x2c/0x168<br /> [ 8.098979] sp : ffff800082b2bd20<br /> [ 8.106599] x29: ffff800082b2bd20 x28: ffff800080107920 x27: ffff800080104d88<br /> [ 8.106611] x26: ffff000003298080 x25: 0000000000000001 x24: 000000000000ff00<br /> [ 8.113707] x23: 0000000000000001 x22: 0000000000000000 x21: 000000000000000e<br /> [ 8.120850] x20: 0000000000000000 x19: 00000000000000ac x18: 0000000000000000<br /> [ 8.135046] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 8.135062] x14: ffff800081567ea8 x13: ffffffffffffffff x12: 0000000000000000<br /> [ 8.135070] x11: 00000000000000c0 x10: 0000000000000b60 x9 : ffff800080109e0c<br /> [ 8.135078] x8 : 1fffe0000069dbc1 x7 : 0000000000000001 x6 : ffff0000034ede00<br /> [ 8.135086] x5 : 0000000000000000 x4 : ffff0000034ede08 x3 : 0000000000000001<br /> [ 8.163460] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 00000000000000ac<br /> [ 8.170560] Call trace:<br /> [ 8.180094] _raw_spin_lock_irq+0x40/0x80 (P)<br /> [ 8.184443] mcp23s08_irq+0x248/0x358<br /> [ 8.184462] irq_thread_fn+0x34/0xb8<br /> [ 8.184470] irq_thread+0x1a4/0x310<br /> [ 8.195093] kthread+0x13c/0x150<br /> [ 8.198309] ret_from_fork+0x10/0x20<br /> [ 8.201850] Code: d65f03c0 d2800002 52800023 f9800011 (885ffc01)<br /> [ 8.207931] ---[ end trace 0000000000000000 ]---<br /> <br /> This issue has always been present, but has been latent until commit<br /> "f9f4fda15e72" ("pinctrl: mcp23s08: init reg_defaults from HW at probe and<br /> switch cache type"), which correctly removed reg_defaults from the regmap<br /> and as a side effect changed the behavior of the interrupt handler so that<br /> the real value of the MCP_GPINTEN register is now being read from the chip<br /> instead of using a bogus 0 default value; a non-zero value for this<br /> register can trigger the invocation of a nested handler which may not exist<br /> (yet).<br /> Fix this issue by disabling all pin interrupts during initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ioam6: fix OOB and missing lock<br /> <br /> When trace-&gt;type.bit6 is set:<br /> <br /> if (trace-&gt;type.bit6) {<br /> ...<br /> queue = skb_get_tx_queue(dev, skb);<br /> qdisc = rcu_dereference(queue-&gt;qdisc);<br /> <br /> This code can lead to an out-of-bounds access of the dev-&gt;_tx[] array<br /> when is_input is true. In such a case, the packet is on the RX path and<br /> skb-&gt;queue_mapping contains the RX queue index of the ingress device. If<br /> the ingress device has more RX queues than the egress device (dev) has<br /> TX queues, skb_get_queue_mapping(skb) will exceed dev-&gt;num_tx_queues.<br /> Add a check to avoid this situation since skb_get_tx_queue() does not<br /> clamp the index. This issue has also revealed that per queue visibility<br /> cannot be accurate and will be replaced later as a new feature.<br /> <br /> While at it, add missing lock around qdisc_qstats_qlen_backlog(). The<br /> function __ioam6_fill_trace_data() is called from both softirq and<br /> process contexts, hence the use of spin_lock_bh() here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: make hash table per queue<br /> <br /> Sharing a global hash table among all queues is tempting, but<br /> it can cause crash:<br /> <br /> BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> [..]<br /> nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]<br /> nfnetlink_rcv_msg+0x46a/0x930<br /> kmem_cache_alloc_node_noprof+0x11e/0x450<br /> <br /> struct nf_queue_entry is freed via kfree, but parallel cpu can still<br /> encounter such an nf_queue_entry when walking the list.<br /> <br /> Alternative fix is to free the nf_queue_entry via kfree_rcu() instead,<br /> but as we have to alloc/free for each skb this will cause more mem<br /> pressure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: algif_aead - Fix minimum RX size check for decryption<br /> <br /> The check for the minimum receive buffer size did not take the<br /> tag size into account during decryption. Fix this by adding the<br /> required extra length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Skip discovery table for offline dies<br /> <br /> This warning can be triggered if NUMA is disabled and the system<br /> boots with fewer CPUs than the number of CPUs in die 0.<br /> <br /> WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]<br /> <br /> Currently, the discovery table continues to be parsed even if all CPUs<br /> in the associated die are offline. This can lead to an array overflow<br /> at "pmu-&gt;boxes[die] = box" in uncore_pci_pmu_register(), which may<br /> trigger the warning above or cause other issues.