Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()<br /> <br /> syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].<br /> <br /> Call pskb_inet_may_pull() to fix this, and initialize ipv6h<br /> variable after this call as it can change skb-&gt;head.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321<br /> ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727<br /> __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845<br /> ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888<br /> gre_rcv+0x143f/0x1870<br /> ip6_protocol_deliver_rcu+0xda6/0x2a60 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:461 [inline]<br /> ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310<br /> __netif_receive_skb_one_core net/core/dev.c:5532 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646<br /> netif_receive_skb_internal net/core/dev.c:5732 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5791<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555<br /> tun_get_user+0x53af/0x66d0 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:2084 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0x786/0x1200 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/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560<br /> __alloc_skb+0x318/0x740 net/core/skbuff.c:651<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334<br /> sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787<br /> tun_alloc_skb drivers/net/tun.c:1531 [inline]<br /> tun_get_user+0x1e8a/0x66d0 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:2084 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0x786/0x1200 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/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix removing a namespace with conflicting altnames<br /> <br /> Mark reports a BUG() when a net namespace is removed.<br /> <br /> kernel BUG at net/core/dev.c:11520!<br /> <br /> Physical interfaces moved outside of init_net get "refunded"<br /> to init_net when that namespace disappears. The main interface<br /> name may get overwritten in the process if it would have<br /> conflicted. We need to also discard all conflicting altnames.<br /> Recent fixes addressed ensuring that altnames get moved<br /> with the main interface, which surfaced this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: Drop support for ETH_P_TR_802_2.<br /> <br /> syzbot reported an uninit-value bug below. [0]<br /> <br /> llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2<br /> (0x0011), and syzbot abused the latter to trigger the bug.<br /> <br /> write$tun(r0, &amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, &amp;#39;)&amp;#39;, "90e5dd"}}}}, 0x16)<br /> <br /> llc_conn_handler() initialises local variables {saddr,daddr}.mac<br /> based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes<br /> them to __llc_lookup().<br /> <br /> However, the initialisation is done only when skb-&gt;protocol is<br /> htons(ETH_P_802_2), otherwise, __llc_lookup_established() and<br /> __llc_lookup_listener() will read garbage.<br /> <br /> The missing initialisation existed prior to commit 211ed865108e<br /> ("net: delete all instances of special processing for token ring").<br /> <br /> It removed the part to kick out the token ring stuff but forgot to<br /> close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().<br /> <br /> Let&amp;#39;s remove llc_tr_packet_type and complete the deprecation.<br /> <br /> [0]:<br /> BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90<br /> __llc_lookup_established+0xe9d/0xf90<br /> __llc_lookup net/llc/llc_conn.c:611 [inline]<br /> llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791<br /> llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206<br /> __netif_receive_skb_one_core net/core/dev.c:5527 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641<br /> netif_receive_skb_internal net/core/dev.c:5727 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5786<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555<br /> tun_get_user+0x53af/0x66d0 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:2020 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x8ef/0x1490 fs/read_write.c:584<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:637<br /> __do_sys_write fs/read_write.c:649 [inline]<br /> __se_sys_write fs/read_write.c:646 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:646<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Local variable daddr created at:<br /> llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783<br /> llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206<br /> <br /> CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: make llc_ui_sendmsg() more robust against bonding changes<br /> <br /> syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no<br /> headroom, but subsequently trying to push 14 bytes of Ethernet header [1]<br /> <br /> Like some others, llc_ui_sendmsg() releases the socket lock before<br /> calling sock_alloc_send_skb().<br /> Then it acquires it again, but does not redo all the sanity checks<br /> that were performed.<br /> <br /> This fix:<br /> <br /> - Uses LL_RESERVED_SPACE() to reserve space.<br /> - Check all conditions again after socket lock is held again.<br /> - Do not account Ethernet header for mtu limitation.<br /> <br /> [1]<br /> <br /> skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0<br /> <br /> kernel BUG at net/core/skbuff.c:193 !<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : skb_panic net/core/skbuff.c:189 [inline]<br /> pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203<br /> lr : skb_panic net/core/skbuff.c:189 [inline]<br /> lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203<br /> sp : ffff800096f97000<br /> x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000<br /> x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2<br /> x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0<br /> x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce<br /> x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001<br /> x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400<br /> x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714<br /> x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089<br /> Call trace:<br /> skb_panic net/core/skbuff.c:189 [inline]<br /> skb_under_panic+0x13c/0x140 net/core/skbuff.c:203<br /> skb_push+0xf0/0x108 net/core/skbuff.c:2451<br /> eth_header+0x44/0x1f8 net/ethernet/eth.c:83<br /> dev_hard_header include/linux/netdevice.h:3188 [inline]<br /> llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33<br /> llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85<br /> llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]<br /> llc_sap_next_state net/llc/llc_sap.c:182 [inline]<br /> llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209<br /> llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270<br /> llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> sock_sendmsg+0x194/0x274 net/socket.c:767<br /> splice_to_socket+0x7cc/0xd58 fs/splice.c:881<br /> do_splice_from fs/splice.c:933 [inline]<br /> direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142<br /> splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088<br /> do_splice_direct+0x20c/0x348 fs/splice.c:1194<br /> do_sendfile+0x4bc/0xc70 fs/read_write.c:1254<br /> __do_sys_sendfile64 fs/read_write.c:1322 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1308 [inline]<br /> __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308<br /> __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155<br /> el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595<br /> Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: rely on mac80211 debugfs handling for vif<br /> <br /> mac80211 started to delete debugfs entries in certain cases, causing a<br /> ath11k to crash when it tried to delete the entries later. Fix this by<br /> relying on mac80211 to delete the entries when appropriate and adding<br /> them from the vif_add_debugfs handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: always initialize struct msghdr completely<br /> <br /> syzbot complains that msg-&gt;msg_get_inq value can be uninitialized [1]<br /> <br /> struct msghdr got many new fields recently, we should always make<br /> sure their values is zero by default.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571<br /> tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571<br /> inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879<br /> sock_recvmsg_nosec net/socket.c:1044 [inline]<br /> sock_recvmsg+0x12b/0x1e0 net/socket.c:1066<br /> __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538<br /> nbd_read_reply drivers/block/nbd.c:732 [inline]<br /> recv_work+0x262/0x3100 drivers/block/nbd.c:863<br /> process_one_work kernel/workqueue.c:2627 [inline]<br /> process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700<br /> worker_thread+0xf45/0x1490 kernel/workqueue.c:2781<br /> kthread+0x3ed/0x540 kernel/kthread.c:388<br /> ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242<br /> <br /> Local variable msg created at:<br /> __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513<br /> nbd_read_reply drivers/block/nbd.c:732 [inline]<br /> recv_work+0x262/0x3100 drivers/block/nbd.c:863<br /> <br /> CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023<br /> Workqueue: nbd5-recv recv_work

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 /> PCI: switchtec: Fix stdev_release() crash after surprise hot remove<br /> <br /> A PCI device hot removal may occur while stdev-&gt;cdev is held open. The call<br /> to stdev_release() then happens during close or exit, at a point way past<br /> switchtec_pci_remove(). Otherwise the last ref would vanish with the<br /> trailing put_device(), just before return.<br /> <br /> At that later point in time, the devm cleanup has already removed the<br /> stdev-&gt;mmio_mrpc mapping. Also, the stdev-&gt;pdev reference was not a counted<br /> one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause<br /> a fatal page fault, and the subsequent dma_free_coherent(), if reached,<br /> would pass a stale &amp;stdev-&gt;pdev-&gt;dev pointer.<br /> <br /> Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after<br /> stdev_kill(). Counting the stdev-&gt;pdev ref is now optional, but may prevent<br /> future accidents.<br /> <br /> Reproducible via the script at<br /> https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block/rnbd-srv: Check for unlikely string overflow<br /> <br /> Since "dev_search_path" can technically be as large as PATH_MAX,<br /> there was a risk of truncation when copying it and a second string<br /> into "full_path" since it was also PATH_MAX sized. The W=1 builds were<br /> reporting this warning:<br /> <br /> drivers/block/rnbd/rnbd-srv.c: In function &amp;#39;process_msg_open.isra&amp;#39;:<br /> drivers/block/rnbd/rnbd-srv.c:616:51: warning: &amp;#39;%s&amp;#39; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]<br /> 616 | snprintf(full_path, PATH_MAX, "%s/%s",<br /> | ^~<br /> In function &amp;#39;rnbd_srv_get_full_path&amp;#39;,<br /> inlined from &amp;#39;process_msg_open.isra&amp;#39; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: &amp;#39;snprintf&amp;#39; output between 2 and 4351 bytes into a destination of size 4096<br /> 616 | snprintf(full_path, PATH_MAX, "%s/%s",<br /> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> 617 | dev_search_path, dev_name);<br /> | ~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> To fix this, unconditionally check for truncation (as was already done<br /> for the case where "%SESSNAME%" was present).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/ram: Fix crash when setting number of cpus to an odd number<br /> <br /> When the number of cpu cores is adjusted to 7 or other odd numbers,<br /> the zone size will become an odd number.<br /> The address of the zone will become:<br /> addr of zone0 = BASE<br /> addr of zone1 = BASE + zone_size<br /> addr of zone2 = BASE + zone_size*2<br /> ...<br /> The address of zone1/3/5/7 will be mapped to non-alignment va.<br /> Eventually crashes will occur when accessing these va.<br /> <br /> So, use ALIGN_DOWN() to make sure the zone size is even<br /> to avoid this bug.

An out-of-bounds stack write flaw was found in unixODBC on 64-bit architectures where the caller has 4 bytes and callee writes 8 bytes. This issue may go unnoticed on little-endian architectures, while big-endian architectures can be broken.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work<br /> <br /> idev-&gt;mc_ifc_count can be written over without proper locking.<br /> <br /> Originally found by syzbot [1], fix this issue by encapsulating calls<br /> to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with<br /> mutex_lock() and mutex_unlock() accordingly as these functions<br /> should only be called with mc_lock per their declarations.<br /> <br /> [1]<br /> BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work<br /> <br /> write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:<br /> mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]<br /> ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725<br /> addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949<br /> addrconf_notify+0x310/0x980<br /> notifier_call_chain kernel/notifier.c:93 [inline]<br /> raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461<br /> __dev_notify_flags+0x205/0x3d0<br /> dev_change_flags+0xab/0xd0 net/core/dev.c:8685<br /> do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916<br /> rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3717 [inline]<br /> rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754<br /> rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558<br /> netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545<br /> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]<br /> netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368<br /> netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910<br /> ...<br /> <br /> write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:<br /> mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653<br /> process_one_work kernel/workqueue.c:2627 [inline]<br /> process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700<br /> worker_thread+0x525/0x730 kernel/workqueue.c:2781<br /> ...