Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: discard table flag update with pending basechain deletion<br /> <br /> Hook unregistration is deferred to the commit phase, same occurs with<br /> hook updates triggered by the table dormant flag. When both commands are<br /> combined, this results in deleting a basechain while leaving its hook<br /> still registered in the core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: module: prevent NULL pointer dereference in vsnprintf()<br /> <br /> In of_modalias(), we can get passed the str and len parameters which would<br /> cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr<br /> when the length is also 0. Also, we need to filter out the negative values<br /> of the len parameter as these will result in a really huge buffer since<br /> snprintf() takes size_t parameter while ours is ssize_t...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the Svace static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: hold io_buffer_list reference over mmap<br /> <br /> If we look up the kbuf, ensure that it doesn&amp;#39;t get unregistered until<br /> after we&amp;#39;re done with it. Since we&amp;#39;re inside mmap, we cannot safely use<br /> the io_uring lock. Rely on the fact that we can lookup the buffer list<br /> under RCU now and grab a reference to it, preventing it from being<br /> unregistered until we&amp;#39;re done with it. The lookup returns the<br /> io_buffer_list directly with it referenced.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP<br /> <br /> Jan Schunk reports that his small NFS servers suffer from memory<br /> exhaustion after just a few days. A bisect shows that commit<br /> e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single<br /> sock_sendmsg() call") is the first bad commit.<br /> <br /> That commit assumed that sock_sendmsg() releases all the pages in<br /> the underlying bio_vec array, but the reality is that it doesn&amp;#39;t.<br /> svc_xprt_release() releases the rqst&amp;#39;s response pages, but the<br /> record marker page fragment isn&amp;#39;t one of those, so it is never<br /> released.<br /> <br /> This is a narrow fix that can be applied to stable kernels. A<br /> more extensive fix is in the works.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe<br /> <br /> In function pci1xxxx_spi_probe, there is a potential null pointer that<br /> may be caused by a failed memory allocation by the function devm_kzalloc.<br /> Hence, a null pointer check needs to be added to prevent null pointer<br /> dereferencing later in the code.<br /> <br /> To fix this issue, spi_bus-&gt;spi_int[iter] should be checked. The memory<br /> allocated by devm_kzalloc will be automatically released, so just directly<br /> return -ENOMEM without worrying about memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxbf_gige: stop interface during shutdown<br /> <br /> The mlxbf_gige driver intermittantly encounters a NULL pointer<br /> exception while the system is shutting down via "reboot" command.<br /> The mlxbf_driver will experience an exception right after executing<br /> its shutdown() method. One example of this exception is:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000<br /> [0000000000000070] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] SMP<br /> CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1<br /> Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]<br /> lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]<br /> sp : ffff8000080d3c10<br /> x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58<br /> x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008<br /> x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128<br /> x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff<br /> x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7<br /> x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101<br /> x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404<br /> x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080<br /> x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]<br /> mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]<br /> __napi_poll+0x40/0x1c8<br /> net_rx_action+0x314/0x3a0<br /> __do_softirq+0x128/0x334<br /> run_ksoftirqd+0x54/0x6c<br /> smpboot_thread_fn+0x14c/0x190<br /> kthread+0x10c/0x110<br /> ret_from_fork+0x10/0x20<br /> Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)<br /> ---[ end trace 7cc3941aa0d8e6a4 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> Kernel Offset: 0x4ce722520000 from 0xffff800008000000<br /> PHYS_OFFSET: 0x80000000<br /> CPU features: 0x000005c1,a3330e5a<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> During system shutdown, the mlxbf_gige driver&amp;#39;s shutdown() is always executed.<br /> However, the driver&amp;#39;s stop() method will only execute if networking interface<br /> configuration logic within the Linux distribution has been setup to do so.<br /> <br /> If shutdown() executes but stop() does not execute, NAPI remains enabled<br /> and this can lead to an exception if NAPI is scheduled while the hardware<br /> interface has only been partially deinitialized.<br /> <br /> The networking interface managed by the mlxbf_gige driver must be properly<br /> stopped during system shutdown so that IFF_UP is cleared, the hardware<br /> interface is put into a clean state, and NAPI is fully deinitialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: fix use-after-free bugs caused by ax25_ds_del_timer<br /> <br /> When the ax25 device is detaching, the ax25_dev_device_down()<br /> calls ax25_ds_del_timer() to cleanup the slave_timer. When<br /> the timer handler is running, the ax25_ds_del_timer() that<br /> calls del_timer() in it will return directly. As a result,<br /> the use-after-free bugs could happen, one of the scenarios<br /> is shown below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | ax25_ds_timeout()<br /> ax25_dev_device_down() |<br /> ax25_ds_del_timer() |<br /> del_timer() |<br /> ax25_dev_put() //FREE |<br /> | ax25_dev-&gt; //USE<br /> <br /> In order to mitigate bugs, when the device is detaching, use<br /> timer_shutdown_sync() to stop the timer.

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