Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Fix incorrect descriptor free behavior<br /> <br /> ENA has two types of TX queues:<br /> - queues which only process TX packets arriving from the network stack<br /> - queues which only process TX packets forwarded to it by XDP_REDIRECT<br /> or XDP_TX instructions<br /> <br /> The ena_free_tx_bufs() cycles through all descriptors in a TX queue<br /> and unmaps + frees every descriptor that hasn&amp;#39;t been acknowledged yet<br /> by the device (uncompleted TX transactions).<br /> The function assumes that the processed TX queue is necessarily from<br /> the first category listed above and ends up using napi_consume_skb()<br /> for descriptors belonging to an XDP specific queue.<br /> <br /> This patch solves a bug in which, in case of a VF reset, the<br /> descriptors aren&amp;#39;t freed correctly, leading to crashes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Properly link new fs rules into the tree<br /> <br /> Previously, add_rule_fg would only add newly created rules from the<br /> handle into the tree when they had a refcount of 1. On the other hand,<br /> create_flow_handle tries hard to find and reference already existing<br /> identical rules instead of creating new ones.<br /> <br /> These two behaviors can result in a situation where create_flow_handle<br /> 1) creates a new rule and references it, then<br /> 2) in a subsequent step during the same handle creation references it<br /> again,<br /> resulting in a rule with a refcount of 2 that is not linked into the<br /> tree, will have a NULL parent and root and will result in a crash when<br /> the flow group is deleted because del_sw_hw_rule, invoked on rule<br /> deletion, assumes node-&gt;parent is != NULL.<br /> <br /> This happened in the wild, due to another bug related to incorrect<br /> handling of duplicate pkt_reformat ids, which lead to the code in<br /> create_flow_handle incorrectly referencing a just-added rule in the same<br /> flow handle, resulting in the problem described above. Full details are<br /> at [1].<br /> <br /> This patch changes add_rule_fg to add new rules without parents into<br /> the tree, properly initializing them and avoiding the crash. This makes<br /> it more consistent with how rules are added to an FTE in<br /> create_flow_handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: complete validation of user input<br /> <br /> In my recent commit, I missed that do_replace() handlers<br /> use copy_from_sockptr() (which I fixed), followed<br /> by unsafe copy_from_sockptr_offset() calls.<br /> <br /> In all functions, we can perform the @optlen validation<br /> before even calling xt_alloc_table_info() with the following<br /> check:<br /> <br /> if ((u64)optlen

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix not validating setsockopt user input<br /> <br /> Check user input length before copying data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: Fix not validating setsockopt user input<br /> <br /> syzbot reported rfcomm_sock_setsockopt_old() is copying data without<br /> checking user input length.<br /> <br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset<br /> include/linux/sockptr.h:49 [inline]<br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr<br /> include/linux/sockptr.h:55 [inline]<br /> BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old<br /> net/bluetooth/rfcomm/sock.c:632 [inline]<br /> BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70<br /> net/bluetooth/rfcomm/sock.c:673<br /> Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: Fix not validating setsockopt user input<br /> <br /> syzbot reported sco_sock_setsockopt() is copying data without<br /> checking user input length.<br /> <br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset<br /> include/linux/sockptr.h:49 [inline]<br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr<br /> include/linux/sockptr.h:55 [inline]<br /> BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90<br /> net/bluetooth/sco.c:893<br /> Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr<br /> <br /> Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it<br /> still means hlist_for_each_entry_rcu can return an item that got removed<br /> from the list. The memory itself of such item is not freed thanks to RCU<br /> but nothing guarantees the actual content of the memory is sane.<br /> <br /> In particular, the reference count can be zero. This can happen if<br /> ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry<br /> from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all<br /> references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough<br /> timing, this can happen:<br /> <br /> 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.<br /> <br /> 2. Then, the whole ipv6_del_addr is executed for the given entry. The<br /> reference count drops to zero and kfree_rcu is scheduled.<br /> <br /> 3. ipv6_get_ifaddr continues and tries to increments the reference count<br /> (in6_ifa_hold).<br /> <br /> 4. The rcu is unlocked and the entry is freed.<br /> <br /> 5. The freed entry is returned.<br /> <br /> Prevent increasing of the reference count in such case. The name<br /> in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.<br /> <br /> [ 41.506330] refcount_t: addition on 0; use-after-free.<br /> [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130<br /> [ 41.507413] Modules linked in: veth bridge stp llc<br /> [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14<br /> [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> [ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130<br /> [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff<br /> [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282<br /> [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000<br /> [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900<br /> [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff<br /> [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000<br /> [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48<br /> [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000<br /> [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0<br /> [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 41.516799] Call Trace:<br /> [ 41.517037] <br /> [ 41.517249] ? __warn+0x7b/0x120<br /> [ 41.517535] ? refcount_warn_saturate+0xa5/0x130<br /> [ 41.517923] ? report_bug+0x164/0x190<br /> [ 41.518240] ? handle_bug+0x3d/0x70<br /> [ 41.518541] ? exc_invalid_op+0x17/0x70<br /> [ 41.520972] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 41.521325] ? refcount_warn_saturate+0xa5/0x130<br /> [ 41.521708] ipv6_get_ifaddr+0xda/0xe0<br /> [ 41.522035] inet6_rtm_getaddr+0x342/0x3f0<br /> [ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10<br /> [ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0<br /> [ 41.523102] ? netlink_unicast+0x30f/0x390<br /> [ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> [ 41.523832] netlink_rcv_skb+0x53/0x100<br /> [ 41.524157] netlink_unicast+0x23b/0x390<br /> [ 41.524484] netlink_sendmsg+0x1f2/0x440<br /> [ 41.524826] __sys_sendto+0x1d8/0x1f0<br /> [ 41.525145] __x64_sys_sendto+0x1f/0x30<br /> [ 41.525467] do_syscall_64+0xa5/0x1b0<br /> [ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a<br /> [ 41.526213] RIP: 0033:0x7fbc4cfcea9a<br /> [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89<br /> [ 41.527942] RSP: 002b:00007f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()<br /> <br /> Subject: [PATCH] drm/panfrost: Fix the error path in<br /> panfrost_mmu_map_fault_addr()<br /> <br /> If some the pages or sgt allocation failed, we shouldn&amp;#39;t release the<br /> pages ref we got earlier, otherwise we will end up with unbalanced<br /> get/put_pages() calls. We should instead leave everything in place<br /> and let the BO release function deal with extra cleanup when the object<br /> is destroyed, or let the fault handler try again next time it&amp;#39;s called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ast: Fix soft lockup<br /> <br /> There is a while-loop in ast_dp_set_on_off() that could lead to<br /> infinite-loop. This is because the register, VGACRI-Dx, checked in<br /> this API is a scratch register actually controlled by a MCU, named<br /> DPMCU, in BMC.<br /> <br /> These scratch registers are protected by scu-lock. If suc-lock is not<br /> off, DPMCU can not update these registers and then host will have soft<br /> lockup due to never updated status.<br /> <br /> DPMCU is used to control DP and relative registers to handshake with<br /> host&amp;#39;s VGA driver. Even the most time-consuming task, DP&amp;#39;s link<br /> training, is less than 100ms. 200ms should be enough.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix deadlock in context_xa<br /> <br /> ivpu_device-&gt;context_xa is locked both in kernel thread and IRQ context.<br /> It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization<br /> otherwise the lock could be acquired from a thread and interrupted by<br /> an IRQ that locks it for the second time causing the deadlock.<br /> <br /> This deadlock was reported by lockdep and observed in internal tests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Avoid sg device teardown race<br /> <br /> sg_remove_sfp_usercontext() must not use sg_device_destroy() after calling<br /> scsi_device_put().<br /> <br /> sg_device_destroy() is accessing the parent scsi_device request_queue which<br /> will already be set to NULL when the preceding call to scsi_device_put()<br /> removed the last reference to the parent scsi_device.<br /> <br /> The resulting NULL pointer exception will then crash the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix WARN_ON in iommu probe path<br /> <br /> Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed<br /> devices") adds all devices probed by the iommu driver in a rbtree<br /> indexed by the source ID of each device. It assumes that each device<br /> has a unique source ID. This assumption is incorrect and the VT-d<br /> spec doesn&amp;#39;t state this requirement either.<br /> <br /> The reason for using a rbtree to track devices is to look up the device<br /> with PCI bus and devfunc in the paths of handling ATS invalidation time<br /> out error and the PRI I/O page faults. Both are PCI ATS feature related.<br /> <br /> Only track the devices that have PCI ATS capabilities in the rbtree to<br /> avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some<br /> platforms below kernel splat will be displayed and the iommu probe results<br /> in failure.<br /> <br /> WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90<br /> Call Trace:<br /> <br /> ? __warn+0x7e/0x180<br /> ? intel_iommu_probe_device+0x319/0xd90<br /> ? report_bug+0x1f8/0x200<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? intel_iommu_probe_device+0x319/0xd90<br /> ? debug_mutex_init+0x37/0x50<br /> __iommu_probe_device+0xf2/0x4f0<br /> iommu_probe_device+0x22/0x70<br /> iommu_bus_notifier+0x1e/0x40<br /> notifier_call_chain+0x46/0x150<br /> blocking_notifier_call_chain+0x42/0x60<br /> bus_notify+0x2f/0x50<br /> device_add+0x5ed/0x7e0<br /> platform_device_add+0xf5/0x240<br /> mfd_add_devices+0x3f9/0x500<br /> ? preempt_count_add+0x4c/0xa0<br /> ? up_write+0xa2/0x1b0<br /> ? __debugfs_create_file+0xe3/0x150<br /> intel_lpss_probe+0x49f/0x5b0<br /> ? pci_conf1_write+0xa3/0xf0<br /> intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci]<br /> pci_device_probe+0x95/0x120<br /> really_probe+0xd9/0x370<br /> ? __pfx___driver_attach+0x10/0x10<br /> __driver_probe_device+0x73/0x150<br /> driver_probe_device+0x19/0xa0<br /> __driver_attach+0xb6/0x180<br /> ? __pfx___driver_attach+0x10/0x10<br /> bus_for_each_dev+0x77/0xd0<br /> bus_add_driver+0x114/0x210<br /> driver_register+0x5b/0x110<br /> ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci]<br /> do_one_initcall+0x57/0x2b0<br /> ? kmalloc_trace+0x21e/0x280<br /> ? do_init_module+0x1e/0x210<br /> do_init_module+0x5f/0x210<br /> load_module+0x1d37/0x1fc0<br /> ? init_module_from_file+0x86/0xd0<br /> init_module_from_file+0x86/0xd0<br /> idempotent_init_module+0x17c/0x230<br /> __x64_sys_finit_module+0x56/0xb0<br /> do_syscall_64+0x6e/0x140<br /> entry_SYSCALL_64_after_hwframe+0x71/0x79