Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()<br /> <br /> null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)<br /> and parse_lease_state() return NULL.<br /> <br /> Fix this by check if &amp;#39;lease_ctx_info&amp;#39; is NULL.<br /> <br /> Additionally, remove the redundant parentheses in<br /> parse_durable_handle_context().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()<br /> <br /> When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the<br /> first one sets &amp;#39;ubq-&gt;ubq_daemon&amp;#39; to NULL, and the second one triggers<br /> WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference<br /> issue.<br /> <br /> Fix it by adding the check in ublk_ctrl_start_recovery() and return<br /> immediately in case of zero &amp;#39;ub-&gt;nr_queues_ready&amp;#39;.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x75/0x170<br /> ? exc_page_fault+0x64/0x140<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180<br /> ublk_ctrl_uring_cmd+0x4f7/0x6c0<br /> ? pick_next_task_idle+0x26/0x40<br /> io_uring_cmd+0x9a/0x1b0<br /> io_issue_sqe+0x193/0x3f0<br /> io_wq_submit_work+0x9b/0x390<br /> io_worker_handle_work+0x165/0x360<br /> io_wq_worker+0xcb/0x2f0<br /> ? finish_task_switch.isra.0+0x203/0x290<br /> ? finish_task_switch.isra.0+0x203/0x290<br /> ? __pfx_io_wq_worker+0x10/0x10<br /> ret_from_fork+0x2d/0x50<br /> ? __pfx_io_wq_worker+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fix kernel crash if commands allocation fails<br /> <br /> If the commands allocation fails in nvmet_tcp_alloc_cmds()<br /> the kernel crashes in nvmet_tcp_release_queue_work() because of<br /> a NULL pointer dereference.<br /> <br /> nvmet: failed to install queue 0 cntlid 1 ret 6<br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000008<br /> <br /> Fix the bug by setting queue-&gt;nr_cmds to zero in case<br /> nvmet_tcp_alloc_cmd() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: Fix use-after-free when removing resource in vmci_resource_remove()<br /> <br /> When removing a resource from vmci_resource_table in<br /> vmci_resource_remove(), the search is performed using the resource<br /> handle by comparing context and resource fields.<br /> <br /> It is possible though to create two resources with different types<br /> but same handle (same context and resource fields).<br /> <br /> When trying to remove one of the resources, vmci_resource_remove()<br /> may not remove the intended one, but the object will still be freed<br /> as in the case of the datagram type in vmci_datagram_destroy_handle().<br /> vmci_resource_table will still hold a pointer to this freed resource<br /> leading to a use-after-free vulnerability.<br /> <br /> BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]<br /> BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147<br /> Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106<br /> print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239<br /> __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425<br /> kasan_report+0x38/0x51 mm/kasan/report.c:442<br /> vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]<br /> vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147<br /> vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182<br /> ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444<br /> kref_put include/linux/kref.h:65 [inline]<br /> vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]<br /> vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195<br /> vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143<br /> __fput+0x261/0xa34 fs/file_table.c:282<br /> task_work_run+0xf0/0x194 kernel/task_work.c:164<br /> tracehook_notify_resume include/linux/tracehook.h:189 [inline]<br /> exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187<br /> exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]<br /> syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313<br /> do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x0<br /> <br /> This change ensures the type is also checked when removing<br /> the resource from vmci_resource_table in vmci_resource_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind<br /> <br /> For primary VM Bus channels, primary_channel pointer is always NULL. This<br /> pointer is valid only for the secondary channels. Also, rescind callback<br /> is meant for primary channels only.<br /> <br /> Fix NULL pointer dereference by retrieving the device_obj from the parent<br /> for the primary channel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF caused by offsets overwrite<br /> <br /> Binder objects are processed and copied individually into the target<br /> buffer during transactions. Any raw data in-between these objects is<br /> copied as well. However, this raw data copy lacks an out-of-bounds<br /> check. If the raw data exceeds the data section size then the copy<br /> overwrites the offsets section. This eventually triggers an error that<br /> attempts to unwind the processed objects. However, at this point the<br /> offsets used to index these objects are now corrupted.<br /> <br /> Unwinding with corrupted offsets can result in decrements of arbitrary<br /> nodes and lead to their premature release. Other users of such nodes are<br /> left with a dangling pointer triggering a use-after-free. This issue is<br /> made evident by the following KASAN report (trimmed):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c<br /> Write of size 4 at addr ffff47fc91598f04 by task binder-util/743<br /> <br /> CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> _raw_spin_lock+0xe4/0x19c<br /> binder_free_buf+0x128/0x434<br /> binder_thread_write+0x8a4/0x3260<br /> binder_ioctl+0x18f0/0x258c<br /> [...]<br /> <br /> Allocated by task 743:<br /> __kmalloc_cache_noprof+0x110/0x270<br /> binder_new_node+0x50/0x700<br /> binder_transaction+0x413c/0x6da8<br /> binder_thread_write+0x978/0x3260<br /> binder_ioctl+0x18f0/0x258c<br /> [...]<br /> <br /> Freed by task 745:<br /> kfree+0xbc/0x208<br /> binder_thread_read+0x1c5c/0x37d4<br /> binder_ioctl+0x16d8/0x258c<br /> [...]<br /> ==================================================================<br /> <br /> To avoid this issue, let&amp;#39;s check that the raw data copy is within the<br /> boundaries of the data section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of/irq: Prevent device address out-of-bounds read in interrupt map walk<br /> <br /> When of_irq_parse_raw() is invoked with a device address smaller than<br /> the interrupt parent node (from #address-cells property), KASAN detects<br /> the following out-of-bounds read when populating the initial match table<br /> (dyndbg="func of_irq_parse_* +p"):<br /> <br /> OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0<br /> OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2<br /> OF: intspec=4<br /> OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2<br /> OF: -&gt; addrsize=3<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0<br /> Read of size 4 at addr ffffff81beca5608 by task bash/764<br /> <br /> CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1<br /> Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023<br /> Call trace:<br /> dump_backtrace+0xdc/0x130<br /> show_stack+0x1c/0x30<br /> dump_stack_lvl+0x6c/0x84<br /> print_report+0x150/0x448<br /> kasan_report+0x98/0x140<br /> __asan_load4+0x78/0xa0<br /> of_irq_parse_raw+0x2b8/0x8d0<br /> of_irq_parse_one+0x24c/0x270<br /> parse_interrupts+0xc0/0x120<br /> of_fwnode_add_links+0x100/0x2d0<br /> fw_devlink_parse_fwtree+0x64/0xc0<br /> device_add+0xb38/0xc30<br /> of_device_add+0x64/0x90<br /> of_platform_device_create_pdata+0xd0/0x170<br /> of_platform_bus_create+0x244/0x600<br /> of_platform_notify+0x1b0/0x254<br /> blocking_notifier_call_chain+0x9c/0xd0<br /> __of_changeset_entry_notify+0x1b8/0x230<br /> __of_changeset_apply_notify+0x54/0xe4<br /> of_overlay_fdt_apply+0xc04/0xd94<br /> ...<br /> <br /> The buggy address belongs to the object at ffffff81beca5600<br /> which belongs to the cache kmalloc-128 of size 128<br /> The buggy address is located 8 bytes inside of<br /> 128-byte region [ffffff81beca5600, ffffff81beca5680)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4<br /> head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0<br /> flags: 0x8000000000010200(slab|head|zone=2)<br /> raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300<br /> raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ^<br /> ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc<br /> ==================================================================<br /> OF: -&gt; got it !<br /> <br /> Prevent the out-of-bounds read by copying the device address into a<br /> buffer of sufficient size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: sanity check symbolic link size<br /> <br /> Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.<br /> <br /> This is caused by an uninitialised page, which is ultimately caused<br /> by a corrupted symbolic link size read from disk.<br /> <br /> The reason why the corrupted symlink size causes an uninitialised<br /> page is due to the following sequence of events:<br /> <br /> 1. squashfs_read_inode() is called to read the symbolic<br /> link from disk. This assigns the corrupted value<br /> 3875536935 to inode-&gt;i_size.<br /> <br /> 2. Later squashfs_symlink_read_folio() is called, which assigns<br /> this corrupted value to the length variable, which being a<br /> signed int, overflows producing a negative number.<br /> <br /> 3. The following loop that fills in the page contents checks that<br /> the copied bytes is less than length, which being negative means<br /> the loop is skipped, producing an uninitialised page.<br /> <br /> This patch adds a sanity check which checks that the symbolic<br /> link size is not larger than expected.<br /> <br /> --<br /> <br /> V2: fix spelling mistake.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: uinput - reject requests with unreasonable number of slots<br /> <br /> <br /> When exercising uinput interface syzkaller may try setting up device<br /> with a really large number of slots, which causes memory allocation<br /> failure in input_mt_init_slots(). While this allocation failure is<br /> handled properly and request is rejected, it results in syzkaller<br /> reports. Additionally, such request may put undue burden on the<br /> system which will try to free a lot of memory for a bogus request.<br /> <br /> Fix it by limiting allowed number of slots to 100. This can easily<br /> be extended if we see devices that can track more than 100 contacts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: amd_sfh: free driver_data after destroying hid device<br /> <br /> HID driver callbacks aren&amp;#39;t called anymore once hid_destroy_device() has<br /> been called. Hence, hid driver_data should be freed only after the<br /> hid_destroy_device() function returned as driver_data is used in several<br /> callbacks.<br /> <br /> I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling<br /> KASAN to debug memory allocation, I got this output:<br /> <br /> [ 13.050438] ==================================================================<br /> [ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]<br /> [ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3<br /> [ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479<br /> <br /> [ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0<br /> [ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024<br /> [ 13.067860] Call Trace:<br /> [ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8<br /> [ 13.071486] <br /> [ 13.071492] dump_stack_lvl+0x5d/0x80<br /> [ 13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -&gt; 0002)<br /> [ 13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]<br /> [ 13.082199] print_report+0x174/0x505<br /> [ 13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]<br /> [ 13.097464] kasan_report+0xc8/0x150<br /> [ 13.101461] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]<br /> [ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]<br /> [ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]<br /> [ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]<br /> [ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]<br /> [ 13.127404] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.131925] ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]<br /> [ 13.136455] ? _raw_spin_lock_irqsave+0x96/0xf0<br /> [ 13.140197] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 13.143602] ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]<br /> [ 13.147234] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.150446] ? __devm_add_action+0x167/0x1d0<br /> [ 13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]<br /> [ 13.158581] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.161814] platform_probe+0xa2/0x150<br /> [ 13.165029] really_probe+0x1e3/0x8a0<br /> [ 13.168243] __driver_probe_device+0x18c/0x370<br /> [ 13.171500] driver_probe_device+0x4a/0x120<br /> [ 13.175000] __driver_attach+0x190/0x4a0<br /> [ 13.178521] ? __pfx___driver_attach+0x10/0x10<br /> [ 13.181771] bus_for_each_dev+0x106/0x180<br /> [ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 13.188229] ? __pfx_bus_for_each_dev+0x10/0x10<br /> [ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.194382] bus_add_driver+0x29e/0x4d0<br /> [ 13.197328] driver_register+0x1a5/0x360<br /> [ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]<br /> [ 13.203362] do_one_initcall+0xa7/0x380<br /> [ 13.206432] ? __pfx_do_one_initcall+0x10/0x10<br /> [ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 13.213211] ? kasan_unpoison+0x44/0x70<br /> [ 13.216688] do_init_module+0x238/0x750<br /> [ 13.2196<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup<br /> <br /> report_fixup for the Cougar 500k Gaming Keyboard was not verifying<br /> that the report descriptor size was correct before accessing it

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Add missing bridge lock to pci_bus_lock()<br /> <br /> One of the true positives that the cfg_access_lock lockdep effort<br /> identified is this sequence:<br /> <br /> WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70<br /> RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70<br /> Call Trace:<br /> <br /> ? __warn+0x8c/0x190<br /> ? pci_bridge_secondary_bus_reset+0x5d/0x70<br /> ? report_bug+0x1f8/0x200<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? pci_bridge_secondary_bus_reset+0x5d/0x70<br /> pci_reset_bus+0x1d8/0x270<br /> vmd_probe+0x778/0xa10<br /> pci_device_probe+0x95/0x120<br /> <br /> Where pci_reset_bus() users are triggering unlocked secondary bus resets.<br /> Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses<br /> pci_bus_lock() before issuing the reset which locks everything *but* the<br /> bridge itself.<br /> <br /> For the same motivation as adding:<br /> <br /> bridge = pci_upstream_bridge(dev);<br /> if (bridge)<br /> pci_dev_lock(bridge);<br /> <br /> to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add<br /> pci_dev_lock() for @bus-&gt;self to pci_bus_lock().<br /> <br /> [bhelgaas: squash in recursive locking deadlock fix from Keith Busch:<br /> https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]