Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()<br /> <br /> If ulp = kzalloc() fails, the allocated edev will leak because it is<br /> not properly assigned and the cleanup path will not be able to free it.<br /> Fix it by assigning it properly immediately after allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: fix header validation in geneve[6]_xmit_skb<br /> <br /> syzbot is able to trigger an uninit-value in geneve_xmit() [1]<br /> <br /> Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())<br /> uses skb_protocol(skb, true), pskb_inet_may_pull() is only using<br /> skb-&gt;protocol.<br /> <br /> If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&gt;protocol,<br /> pskb_inet_may_pull() does nothing at all.<br /> <br /> If a vlan tag was provided by the caller (af_packet in the syzbot case),<br /> the network header might not point to the correct location, and skb<br /> linear part could be smaller than expected.<br /> <br /> Add skb_vlan_inet_prepare() to perform a complete mac validation.<br /> <br /> Use this in geneve for the moment, I suspect we need to adopt this<br /> more broadly.<br /> <br /> v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest<br /> - Only call __vlan_get_protocol() for vlan types.<br /> <br /> v2,v3 - Addressed Sabrina comments on v1 and v2<br /> <br /> [1]<br /> <br /> BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]<br /> BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030<br /> geneve_xmit_skb drivers/net/geneve.c:910 [inline]<br /> geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030<br /> __netdev_start_xmit include/linux/netdevice.h:4903 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4917 [inline]<br /> xmit_one net/core/dev.c:3531 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547<br /> __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335<br /> dev_queue_xmit include/linux/netdevice.h:3091 [inline]<br /> packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3081 [inline]<br /> packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> __sys_sendto+0x685/0x830 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199<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 /> packet_alloc_skb net/packet/af_packet.c:2930 [inline]<br /> packet_snd net/packet/af_packet.c:3024 [inline]<br /> packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> __sys_sendto+0x685/0x830 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix transmit scheduler resource leak<br /> <br /> Inorder to support shaping and scheduling, Upon class creation<br /> Netdev driver allocates trasmit schedulers.<br /> <br /> The previous patch which added support for Round robin scheduling has<br /> a bug due to which driver is not freeing transmit schedulers post<br /> class deletion.<br /> <br /> This patch fixes the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_uart: properly fix race condition<br /> <br /> The cros_ec_uart_probe() function calls devm_serdev_device_open() before<br /> it calls serdev_device_set_client_ops(). This can trigger a NULL pointer<br /> dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> ...<br /> ? ttyport_receive_buf<br /> <br /> A simplified version of crashing code is as follows:<br /> <br /> static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,<br /> const u8 *data,<br /> size_t count)<br /> {<br /> struct serdev_device *serdev = ctrl-&gt;serdev;<br /> <br /> if (!serdev || !serdev-&gt;ops-&gt;receive_buf) // CRASH!<br /> return 0;<br /> <br /> return serdev-&gt;ops-&gt;receive_buf(serdev, data, count);<br /> }<br /> <br /> It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev-&gt;ops<br /> will also exist. This conflicts with the existing cros_ec_uart_probe()<br /> logic, as it first calls devm_serdev_device_open() (which sets<br /> SERPORT_ACTIVE), and only later sets serdev-&gt;ops via<br /> serdev_device_set_client_ops().<br /> <br /> Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race<br /> condition") attempted to fix a similar race condition, but while doing<br /> so, made the window of error for this race condition to happen much<br /> wider.<br /> <br /> Attempt to fix the race condition again, making sure we fully setup<br /> before calling devm_serdev_device_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix memory leak in hci_req_sync_complete()<br /> <br /> In &amp;#39;hci_req_sync_complete()&amp;#39;, always free the previous sync<br /> request state before assigning reference to a new one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raid1: fix use-after-free for original bio in raid1_write_request()<br /> <br /> r1_bio-&gt;bios[] is used to record new bios that will be issued to<br /> underlying disks, however, in raid1_write_request(), r1_bio-&gt;bios[]<br /> will set to the original bio temporarily. Meanwhile, if blocked rdev<br /> is set, free_r1bio() will be called causing that all r1_bio-&gt;bios[]<br /> to be freed:<br /> <br /> raid1_write_request()<br /> r1_bio = alloc_r1bio(mddev, bio); -&gt; r1_bio-&gt;bios[] is NULL<br /> for (i = 0; i for each rdev in conf<br /> // first rdev is normal<br /> r1_bio-&gt;bios[0] = bio; -&gt; set to original bio<br /> // second rdev is blocked<br /> if (test_bit(Blocked, &amp;rdev-&gt;flags))<br /> break<br /> <br /> if (blocked_rdev)<br /> free_r1bio()<br /> put_all_bios()<br /> bio_put(r1_bio-&gt;bios[0]) -&gt; original bio is freed<br /> <br /> Test scripts:<br /> <br /> mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean<br /> fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \<br /> -iodepth=128 -name=test -direct=1<br /> echo blocked &gt; /sys/block/md0/md/rd2/state<br /> <br /> Test result:<br /> <br /> BUG bio-264 (Not tainted): Object already free<br /> -----------------------------------------------------------------------------<br /> <br /> Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869<br /> kmem_cache_alloc+0x324/0x480<br /> mempool_alloc_slab+0x24/0x50<br /> mempool_alloc+0x6e/0x220<br /> bio_alloc_bioset+0x1af/0x4d0<br /> blkdev_direct_IO+0x164/0x8a0<br /> blkdev_write_iter+0x309/0x440<br /> aio_write+0x139/0x2f0<br /> io_submit_one+0x5ca/0xb70<br /> __do_sys_io_submit+0x86/0x270<br /> __x64_sys_io_submit+0x22/0x30<br /> do_syscall_64+0xb1/0x210<br /> entry_SYSCALL_64_after_hwframe+0x6c/0x74<br /> Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869<br /> kmem_cache_free+0x28c/0x550<br /> mempool_free_slab+0x1f/0x30<br /> mempool_free+0x40/0x100<br /> bio_free+0x59/0x80<br /> bio_put+0xf0/0x220<br /> free_r1bio+0x74/0xb0<br /> raid1_make_request+0xadf/0x1150<br /> md_handle_request+0xc7/0x3b0<br /> md_submit_bio+0x76/0x130<br /> __submit_bio+0xd8/0x1d0<br /> submit_bio_noacct_nocheck+0x1eb/0x5c0<br /> submit_bio_noacct+0x169/0xd40<br /> submit_bio+0xee/0x1d0<br /> blkdev_direct_IO+0x322/0x8a0<br /> blkdev_write_iter+0x309/0x440<br /> aio_write+0x139/0x2f0<br /> <br /> Since that bios for underlying disks are not allocated yet, fix this<br /> problem by using mempool_free() directly to free the r1_bio.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: tlb: Fix TLBI RANGE operand<br /> <br /> KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty<br /> pages are collected by VMM and the page table entries become write<br /> protected during live migration. Unfortunately, the operand passed<br /> to the TLBI RANGE instruction isn&amp;#39;t correctly sorted out due to the<br /> commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()").<br /> It leads to crash on the destination VM after live migration because<br /> TLBs aren&amp;#39;t flushed completely and some of the dirty pages are missed.<br /> <br /> For example, I have a VM where 8GB memory is assigned, starting from<br /> 0x40000000 (1GB). Note that the host has 4KB as the base page size.<br /> In the middile of migration, kvm_tlb_flush_vmid_range() is executed<br /> to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to<br /> __kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3<br /> and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn&amp;#39;t supported<br /> by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned<br /> from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop<br /> in the __flush_tlb_range_op() until the variable @scale underflows<br /> and becomes -9, 0xffff708000040000 is set as the operand. The operand<br /> is wrong since it&amp;#39;s sorted out by __TLBI_VADDR_RANGE() according to<br /> invalid @scale and @num.<br /> <br /> Fix it by extending __TLBI_RANGE_NUM() to support the combination of<br /> SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can<br /> be returned from the macro, meaning the TLBs for 0x200000 pages in the<br /> above example can be flushed in one shoot with SCALE#3 and NUM#31. The<br /> macro TLBI_RANGE_MASK is dropped since no one uses it any more. The<br /> comments are also adjusted accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Do not send RSS key if it is not supported<br /> <br /> There is a bug when setting the RSS options in virtio_net that can break<br /> the whole machine, getting the kernel into an infinite loop.<br /> <br /> Running the following command in any QEMU virtual machine with virtionet<br /> will reproduce this problem:<br /> <br /> # ethtool -X eth0 hfunc toeplitz<br /> <br /> This is how the problem happens:<br /> <br /> 1) ethtool_set_rxfh() calls virtnet_set_rxfh()<br /> <br /> 2) virtnet_set_rxfh() calls virtnet_commit_rss_command()<br /> <br /> 3) virtnet_commit_rss_command() populates 4 entries for the rss<br /> scatter-gather<br /> <br /> 4) Since the command above does not have a key, then the last<br /> scatter-gatter entry will be zeroed, since rss_key_size == 0.<br /> sg_buf_size = vi-&gt;rss_key_size;<br /> <br /> 5) This buffer is passed to qemu, but qemu is not happy with a buffer<br /> with zero length, and do the following in virtqueue_map_desc() (QEMU<br /> function):<br /> <br /> if (!sz) {<br /> virtio_error(vdev, "virtio: zero sized buffers are not allowed");<br /> <br /> 6) virtio_error() (also QEMU function) set the device as broken<br /> <br /> vdev-&gt;broken = true;<br /> <br /> 7) Qemu bails out, and do not repond this crazy kernel.<br /> <br /> 8) The kernel is waiting for the response to come back (function<br /> virtnet_send_command())<br /> <br /> 9) The kernel is waiting doing the following :<br /> <br /> while (!virtqueue_get_buf(vi-&gt;cvq, &amp;tmp) &amp;&amp;<br /> !virtqueue_is_broken(vi-&gt;cvq))<br /> cpu_relax();<br /> <br /> 10) None of the following functions above is true, thus, the kernel<br /> loops here forever. Keeping in mind that virtqueue_is_broken() does<br /> not look at the qemu `vdev-&gt;broken`, so, it never realizes that the<br /> vitio is broken at QEMU side.<br /> <br /> Fix it by not sending RSS commands if the feature is not available in<br /> the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid infinite loop trying to resize local TT<br /> <br /> If the MTU of one of an attached interface becomes too small to transmit<br /> the local translation table then it must be resized to fit inside all<br /> fragments (when enabled) or a single packet.<br /> <br /> But if the MTU becomes too low to transmit even the header + the VLAN<br /> specific part then the resizing of the local TT will never succeed. This<br /> can for example happen when the usable space is 110 bytes and 11 VLANs are<br /> on top of batman-adv. In this case, at least 116 byte would be needed.<br /> There will just be an endless spam of<br /> <br /> batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)<br /> <br /> in the log but the function will never finish. Problem here is that the<br /> timeout will be halved all the time and will then stagnate at 0 and<br /> therefore never be able to reduce the table even more.<br /> <br /> There are other scenarios possible with a similar result. The number of<br /> BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too<br /> high to fit inside a packet. Such a scenario can therefore happen also with<br /> only a single VLAN + 7 non-purgable addresses - requiring at least 120<br /> bytes.<br /> <br /> While this should be handled proactively when:<br /> <br /> * interface with too low MTU is added<br /> * VLAN is added<br /> * non-purgeable local mac is added<br /> * MTU of an attached interface is reduced<br /> * fragmentation setting gets disabled (which most likely requires dropping<br /> attached interfaces)<br /> <br /> not all of these scenarios can be prevented because batman-adv is only<br /> consuming events without the the possibility to prevent these actions<br /> (non-purgable MAC address added, MTU of an attached interface is reduced).<br /> It is therefore necessary to also make sure that the code is able to handle<br /> also the situations when there were already incompatible system<br /> configuration are present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS<br /> <br /> bits_per() rounds up to the next power of two when passed a power of<br /> two. This causes crashes on some machines and configurations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: smbus: fix NULL function pointer dereference<br /> <br /> Baruch reported an OOPS when using the designware controller as target<br /> only. Target-only modes break the assumption of one transfer function<br /> always being available. Fix this by always checking the pointer in<br /> __i2c_transfer.<br /> <br /> [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()<br /> <br /> It was possible to have pick_eevdf() return NULL, which then causes a<br /> NULL-deref. This turned out to be due to entity_eligible() returning<br /> falsely negative because of a s64 multiplcation overflow.<br /> <br /> Specifically, reweight_eevdf() computes the vlag without considering<br /> the limit placed upon vlag as update_entity_lag() does, and then the<br /> scaling multiplication (remember that weight is 20bit fixed point) can<br /> overflow. This then leads to the new vruntime being weird which then<br /> causes the above entity_eligible() to go side-ways and claim nothing<br /> is eligible.<br /> <br /> Thus limit the range of vlag accordingly.<br /> <br /> All this was quite rare, but fatal when it does happen.