Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbmod: prevent kernel-infoleak<br /> <br /> syzbot found that tcf_skbmod_dump() was copying four bytes<br /> from kernel stack to user space [1].<br /> <br /> The issue here is that &amp;#39;struct tc_skbmod&amp;#39; has a four bytes hole.<br /> <br /> We need to clear the structure before filling fields.<br /> <br /> [1]<br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> copy_to_iter include/linux/uio.h:196 [inline]<br /> simple_copy_to_iter net/core/datagram.c:532 [inline]<br /> __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420<br /> skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546<br /> skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]<br /> netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x2c4/0x340 net/socket.c:1068<br /> __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242<br /> __do_sys_recvfrom net/socket.c:2260 [inline]<br /> __se_sys_recvfrom net/socket.c:2256 [inline]<br /> __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was stored to memory at:<br /> pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253<br /> netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317<br /> netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351<br /> nlmsg_unicast include/net/netlink.h:1144 [inline]<br /> nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610<br /> rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741<br /> rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]<br /> tcf_add_notify net/sched/act_api.c:2048 [inline]<br /> tcf_action_add net/sched/act_api.c:2071 [inline]<br /> tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119<br /> rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595<br /> netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559<br /> rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]<br /> netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361<br /> netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> ____sys_sendmsg+0x877/0xb60 net/socket.c:2584<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638<br /> __sys_sendmsg net/socket.c:2667 [inline]<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was stored to memory at:<br /> __nla_put lib/nlattr.c:1041 [inline]<br /> nla_put+0x1c6/0x230 lib/nlattr.c:1099<br /> tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256<br /> tcf_action_dump_old net/sched/act_api.c:1191 [inline]<br /> tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227<br /> tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251<br /> tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628<br /> tcf_add_notify_msg net/sched/act_api.c:2023 [inline]<br /> tcf_add_notify net/sched/act_api.c:2042 [inline]<br /> tcf_action_add net/sched/act_api.c:2071 [inline]<br /> tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119<br /> rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595<br /> netlink_rcv_skb+0x375/0x650 net/netlink/af_netli<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: reject new basechain after table flag update<br /> <br /> When dormant flag is toggled, hooks are disabled in the commit phase by<br /> iterating over current chains in table (existing and new).<br /> <br /> The following configuration allows for an inconsistent state:<br /> <br /> add table x<br /> add chain x y { type filter hook input priority 0; }<br /> add table x { flags dormant; }<br /> add chain x w { type filter hook input priority 1; }<br /> <br /> which triggers the following warning when trying to unregister chain w<br /> which is already unregistered.<br /> <br /> [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260<br /> [...]<br /> [ 127.322519] Call Trace:<br /> [ 127.322521] <br /> [ 127.322524] ? __warn+0x9f/0x1a0<br /> [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260<br /> [ 127.322537] ? report_bug+0x1b1/0x1e0<br /> [ 127.322545] ? handle_bug+0x3c/0x70<br /> [ 127.322552] ? exc_invalid_op+0x17/0x40<br /> [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 127.322563] ? kasan_save_free_info+0x3b/0x60<br /> [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260<br /> [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260<br /> [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260<br /> [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]<br /> [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]<br /> [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

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.