Vulnerabilities

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 /> xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING<br /> <br /> syzbot reported an illegal copy in xsk_setsockopt() [1]<br /> <br /> Make sure to validate setsockopt() @optlen parameter.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420<br /> Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549<br /> <br /> CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420<br /> do_sock_setsockopt+0x3af/0x720 net/socket.c:2311<br /> __sys_setsockopt+0x1ae/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> RIP: 0033:0x7fb40587de69<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69<br /> RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006<br /> RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000<br /> R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08<br /> <br /> <br /> Allocated by task 7549:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:370 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387<br /> kasan_kmalloc include/linux/kasan.h:211 [inline]<br /> __do_kmalloc_node mm/slub.c:3966 [inline]<br /> __kmalloc+0x233/0x4a0 mm/slub.c:3979<br /> kmalloc include/linux/slab.h:632 [inline]<br /> __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869<br /> do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293<br /> __sys_setsockopt+0x1ae/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> The buggy address belongs to the object at ffff888028c6cde0<br /> which belongs to the cache kmalloc-8 of size 8<br /> The buggy address is located 1 bytes to the right of<br /> allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)<br /> <br /> The buggy address belongs to the physical page:<br /> page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c<br /> anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)<br /> page_type: 0xffffffff()<br /> raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001<br /> raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as allocated<br /> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223<br /> set_page_owner include/linux/page_owner.h:31 [inline]<br /> post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533<br /> prep_new_page mm/page_alloc.c:<br /> ---truncated---

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered<br /> <br /> The power_supply frame-work is not really designed for there to be<br /> long living in kernel references to power_supply devices.<br /> <br /> Specifically unregistering a power_supply while some other code has<br /> a reference to it triggers a WARN in power_supply_unregister():<br /> <br /> WARN_ON(atomic_dec_return(&amp;psy-&gt;use_cnt));<br /> <br /> Folllowed by the power_supply still getting removed and the<br /> backing data freed anyway, leaving the tusb1210 charger-detect code<br /> with a dangling reference, resulting in a crash the next time<br /> tusb1210_get_online() is called.<br /> <br /> Fix this by only holding the reference in tusb1210_get_online()<br /> freeing it at the end of the function. Note this still leaves<br /> a theoretical race window, but it avoids the issue when manually<br /> rmmod-ing the charger chip driver during development.