Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erspan: make sure erspan_base_hdr is present in skb-&gt;head<br /> <br /> syzbot reported a problem in ip6erspan_rcv() [1]<br /> <br /> Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make<br /> sure erspan_base_hdr is present in skb linear part (skb-&gt;head)<br /> before getting @ver field from it.<br /> <br /> Add the missing pskb_may_pull() calls.<br /> <br /> v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()<br /> because skb-&gt;head might have changed.<br /> <br /> [1]<br /> <br /> BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]<br /> BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]<br /> BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]<br /> BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610<br /> pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]<br /> pskb_may_pull include/linux/skbuff.h:2756 [inline]<br /> ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]<br /> gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610<br /> ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish net/ipv6/ip6_input.c:483 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492<br /> ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586<br /> dst_input include/net/dst.h:460 [inline]<br /> ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310<br /> __netif_receive_skb_one_core net/core/dev.c:5538 [inline]<br /> __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652<br /> netif_receive_skb_internal net/core/dev.c:5738 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5798<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549<br /> tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048<br /> call_write_iter include/linux/fs.h:2108 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb63/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xe0 fs/read_write.c:652<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3804 [inline]<br /> slab_alloc_node mm/slub.c:3845 [inline]<br /> kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577<br /> __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668<br /> alloc_skb include/linux/skbuff.h:1318 [inline]<br /> alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504<br /> sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795<br /> tun_alloc_skb drivers/net/tun.c:1525 [inline]<br /> tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048<br /> call_write_iter include/linux/fs.h:2108 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb63/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xe0 fs/read_write.c:652<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix kernel panic on unknown packet types<br /> <br /> In the very rare case where a packet type is unknown to the driver,<br /> idpf_rx_process_skb_fields would return early without calling<br /> eth_type_trans to set the skb protocol / the network layer handler.<br /> This is especially problematic if tcpdump is running when such a<br /> packet is received, i.e. it would cause a kernel panic.<br /> <br /> Instead, call eth_type_trans for every single packet, even when<br /> the packet type is unknown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix infinite recursion in fib6_dump_done().<br /> <br /> syzkaller reported infinite recursive calls of fib6_dump_done() during<br /> netlink socket destruction. [1]<br /> <br /> From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then<br /> the response was generated. The following recvmmsg() resumed the dump<br /> for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due<br /> to the fault injection. [0]<br /> <br /> 12:01:34 executing program 3:<br /> r0 = socket$nl_route(0x10, 0x3, 0x0)<br /> sendmsg$nl_route(r0, ... snip ...)<br /> recvmmsg(r0, ... snip ...) (fail_nth: 8)<br /> <br /> Here, fib6_dump_done() was set to nlk_sk(sk)-&gt;cb.done, and the next call<br /> of inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3]. syzkaller stopped<br /> receiving the response halfway through, and finally netlink_sock_destruct()<br /> called nlk_sk(sk)-&gt;cb.done().<br /> <br /> fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-&gt;cb.done() if it<br /> is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() by<br /> nlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, calling<br /> itself recursively and hitting the stack guard page.<br /> <br /> To avoid the issue, let&amp;#39;s set the destructor after kzalloc().<br /> <br /> [0]:<br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 0<br /> CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117)<br /> should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)<br /> should_failslab (mm/slub.c:3733)<br /> kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)<br /> inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)<br /> rtnl_dump_all (net/core/rtnetlink.c:4029)<br /> netlink_dump (net/netlink/af_netlink.c:2269)<br /> netlink_recvmsg (net/netlink/af_netlink.c:1988)<br /> ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)<br /> ___sys_recvmsg (net/socket.c:2846)<br /> do_recvmmsg (net/socket.c:2943)<br /> __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)<br /> <br /> [1]:<br /> BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)<br /> stack guard page: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events netlink_sock_destruct_work<br /> RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)<br /> Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff<br /> RSP: 0018:ffffc9000d980000 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3<br /> RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358<br /> RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000<br /> R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68<br /> FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> <br /> <br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> ...<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> netlink_sock_destruct (net/netlink/af_netlink.c:401)<br /> __sk_destruct (net/core/sock.c:2177 (discriminator 2))<br /> sk_destruct (net/core/sock.c:2224)<br /> __sk_free (net/core/sock.c:2235)<br /> sk_free (net/core/sock.c:2246)<br /> process_one_work (kernel/workqueue.c:3259)<br /> worker_thread (kernel/workqueue.c:3329 kernel/workqueue.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: do not accept non-tunnel GSO skbs landing in a tunnel<br /> <br /> When rx-udp-gro-forwarding is enabled UDP packets might be GROed when<br /> being forwarded. If such packets might land in a tunnel this can cause<br /> various issues and udp_gro_receive makes sure this isn&amp;#39;t the case by<br /> looking for a matching socket. This is performed in<br /> udp4/6_gro_lookup_skb but only in the current netns. This is an issue<br /> with tunneled packets when the endpoint is in another netns. In such<br /> cases the packets will be GROed at the UDP level, which leads to various<br /> issues later on. The same thing can happen with rx-gro-list.<br /> <br /> We saw this with geneve packets being GROed at the UDP level. In such<br /> case gso_size is set; later the packet goes through the geneve rx path,<br /> the geneve header is pulled, the offset are adjusted and frag_list skbs<br /> are not adjusted with regard to geneve. When those skbs hit<br /> skb_fragment, it will misbehave. Different outcomes are possible<br /> depending on what the GROed skbs look like; from corrupted packets to<br /> kernel crashes.<br /> <br /> One example is a BUG_ON[1] triggered in skb_segment while processing the<br /> frag_list. Because gso_size is wrong (geneve header was pulled)<br /> skb_segment thinks there is "geneve header size" of data in frag_list,<br /> although it&amp;#39;s in fact the next packet. The BUG_ON itself has nothing to<br /> do with the issue. This is only one of the potential issues.<br /> <br /> Looking up for a matching socket in udp_gro_receive is fragile: the<br /> lookup could be extended to all netns (not speaking about performances)<br /> but nothing prevents those packets from being modified in between and we<br /> could still not find a matching socket. It&amp;#39;s OK to keep the current<br /> logic there as it should cover most cases but we also need to make sure<br /> we handle tunnel packets being GROed too early.<br /> <br /> This is done by extending the checks in udp_unexpected_gso: GSO packets<br /> lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must<br /> be segmented.<br /> <br /> [1] kernel BUG at net/core/skbuff.c:4408!<br /> RIP: 0010:skb_segment+0xd2a/0xf70<br /> __udp_gso_segment+0xaa/0x560

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: dynamic: Synchronize of_changeset_destroy() with the devlink removals<br /> <br /> In the following sequence:<br /> 1) of_platform_depopulate()<br /> 2) of_overlay_remove()<br /> <br /> During the step 1, devices are destroyed and devlinks are removed.<br /> During the step 2, OF nodes are destroyed but<br /> __of_changeset_entry_destroy() can raise warnings related to missing<br /> of_node_put():<br /> ERROR: memory leak, expected refcount 1 instead of 2 ...<br /> <br /> Indeed, during the devlink removals performed at step 1, the removal<br /> itself releasing the device (and the attached of_node) is done by a job<br /> queued in a workqueue and so, it is done asynchronously with respect to<br /> function calls.<br /> When the warning is present, of_node_put() will be called but wrongly<br /> too late from the workqueue job.<br /> <br /> In order to be sure that any ongoing devlink removals are done before<br /> the of_node destruction, synchronize the of_changeset_destroy() with the<br /> devlink removals.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential UAF in smb2_is_valid_oplock_break()<br /> <br /> Skip sessions that are being teared down (status == SES_EXITING) to<br /> avoid UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential UAF in cifs_stats_proc_write()<br /> <br /> Skip sessions that are being teared down (status == SES_EXITING) to<br /> avoid UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/secretmem: fix GUP-fast succeeding on secretmem folios<br /> <br /> folio_is_secretmem() currently relies on secretmem folios being LRU<br /> folios, to save some cycles.<br /> <br /> However, folios might reside in a folio batch without the LRU flag set, or<br /> temporarily have their LRU flag cleared. Consequently, the LRU flag is<br /> unreliable for this purpose.<br /> <br /> In particular, this is the case when secretmem_fault() allocates a fresh<br /> page and calls filemap_add_folio()-&gt;folio_add_lru(). The folio might be<br /> added to the per-cpu folio batch and won&amp;#39;t get the LRU flag set until the<br /> batch was drained using e.g., lru_add_drain().<br /> <br /> Consequently, folio_is_secretmem() might not detect secretmem folios and<br /> GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel<br /> when we would later try reading/writing to the folio, because the folio<br /> has been unmapped from the directmap.<br /> <br /> Fix it by removing that unreliable check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix vector state restore in rt_sigreturn()<br /> <br /> The RISC-V Vector specification states in "Appendix D: Calling<br /> Convention for Vector State" [1] that "Executing a system call causes<br /> all caller-saved vector registers (v0-v31, vl, vtype) and vstart to<br /> become unspecified.". In the RISC-V kernel this is called "discarding<br /> the vstate".<br /> <br /> Returning from a signal handler via the rt_sigreturn() syscall, vector<br /> discard is also performed. However, this is not an issue since the<br /> vector state should be restored from the sigcontext, and therefore not<br /> care about the vector discard.<br /> <br /> The "live state" is the actual vector register in the running context,<br /> and the "vstate" is the vector state of the task. A dirty live state,<br /> means that the vstate and live state are not in synch.<br /> <br /> When vectorized user_from_copy() was introduced, an bug sneaked in at<br /> the restoration code, related to the discard of the live state.<br /> <br /> An example when this go wrong:<br /> <br /> 1. A userland application is executing vector code<br /> 2. The application receives a signal, and the signal handler is<br /> entered.<br /> 3. The application returns from the signal handler, using the<br /> rt_sigreturn() syscall.<br /> 4. The live vector state is discarded upon entering the<br /> rt_sigreturn(), and the live state is marked as "dirty", indicating<br /> that the live state need to be synchronized with the current<br /> vstate.<br /> 5. rt_sigreturn() restores the vstate, except the Vector registers,<br /> from the sigcontext<br /> 6. rt_sigreturn() restores the Vector registers, from the sigcontext,<br /> and now the vectorized user_from_copy() is used. The dirty live<br /> state from the discard is saved to the vstate, making the vstate<br /> corrupt.<br /> 7. rt_sigreturn() returns to the application, which crashes due to<br /> corrupted vstate.<br /> <br /> Note that the vectorized user_from_copy() is invoked depending on the<br /> value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which<br /> means that vlen has to be larger than 128b for this bug to trigger.<br /> <br /> The fix is simply to mark the live state as non-dirty/clean prior<br /> performing the vstate restore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aio: Fix null ptr deref in aio_complete() wakeup<br /> <br /> list_del_init_careful() needs to be the last access to the wait queue<br /> entry - it effectively unlocks access.<br /> <br /> Previously, finish_wait() would see the empty list head and skip taking<br /> the lock, and then we&amp;#39;d return - but the completion path would still<br /> attempt to do the wakeup after the task_struct pointer had been<br /> overwritten.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/coco: Require seeding RNG with RDRAND on CoCo systems<br /> <br /> There are few uses of CoCo that don&amp;#39;t rely on working cryptography and<br /> hence a working RNG. Unfortunately, the CoCo threat model means that the<br /> VM host cannot be trusted and may actively work against guests to<br /> extract secrets or manipulate computation. Since a malicious host can<br /> modify or observe nearly all inputs to guests, the only remaining source<br /> of entropy for CoCo guests is RDRAND.<br /> <br /> If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole<br /> is meant to gracefully continue on gathering entropy from other sources,<br /> but since there aren&amp;#39;t other sources on CoCo, this is catastrophic.<br /> This is mostly a concern at boot time when initially seeding the RNG, as<br /> after that the consequences of a broken RDRAND are much more<br /> theoretical.<br /> <br /> So, try at boot to seed the RNG using 256 bits of RDRAND output. If this<br /> fails, panic(). This will also trigger if the system is booted without<br /> RDRAND, as RDRAND is essential for a safe CoCo boot.<br /> <br /> Add this deliberately to be "just a CoCo x86 driver feature" and not<br /> part of the RNG itself. Many device drivers and platforms have some<br /> desire to contribute something to the RNG, and add_device_randomness()<br /> is specifically meant for this purpose.<br /> <br /> Any driver can call it with seed data of any quality, or even garbage<br /> quality, and it can only possibly make the quality of the RNG better or<br /> have no effect, but can never make it worse.<br /> <br /> Rather than trying to build something into the core of the RNG, consider<br /> the particular CoCo issue just a CoCo issue, and therefore separate it<br /> all out into driver (well, arch/platform) code.<br /> <br /> [ bp: Massage commit message. ]

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