Vulnerabilities

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]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between direct IO write and fsync when using same fd<br /> <br /> If we have 2 threads that are using the same file descriptor and one of<br /> them is doing direct IO writes while the other is doing fsync, we have a<br /> race where we can end up either:<br /> <br /> 1) Attempt a fsync without holding the inode&amp;#39;s lock, triggering an<br /> assertion failures when assertions are enabled;<br /> <br /> 2) Do an invalid memory access from the fsync task because the file private<br /> points to memory allocated on stack by the direct IO task and it may be<br /> used by the fsync task after the stack was destroyed.<br /> <br /> The race happens like this:<br /> <br /> 1) A user space program opens a file descriptor with O_DIRECT;<br /> <br /> 2) The program spawns 2 threads using libpthread for example;<br /> <br /> 3) One of the threads uses the file descriptor to do direct IO writes,<br /> while the other calls fsync using the same file descriptor.<br /> <br /> 4) Call task A the thread doing direct IO writes and task B the thread<br /> doing fsyncs;<br /> <br /> 5) Task A does a direct IO write, and at btrfs_direct_write() sets the<br /> file&amp;#39;s private to an on stack allocated private with the member<br /> &amp;#39;fsync_skip_inode_lock&amp;#39; set to true;<br /> <br /> 6) Task B enters btrfs_sync_file() and sees that there&amp;#39;s a private<br /> structure associated to the file which has &amp;#39;fsync_skip_inode_lock&amp;#39; set<br /> to true, so it skips locking the inode&amp;#39;s VFS lock;<br /> <br /> 7) Task A completes the direct IO write, and resets the file&amp;#39;s private to<br /> NULL since it had no prior private and our private was stack allocated.<br /> Then it unlocks the inode&amp;#39;s VFS lock;<br /> <br /> 8) Task B enters btrfs_get_ordered_extents_for_logging(), then the<br /> assertion that checks the inode&amp;#39;s VFS lock is held fails, since task B<br /> never locked it and task A has already unlocked it.<br /> <br /> The stack trace produced is the following:<br /> <br /> assertion failed: inode_is_locked(&amp;inode-&gt;vfs_inode), in fs/btrfs/ordered-data.c:983<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/ordered-data.c:983!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8<br /> Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020<br /> RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]<br /> Code: 50 d6 86 c0 e8 (...)<br /> RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246<br /> RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800<br /> RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38<br /> R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800<br /> R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000<br /> FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x14/0x24<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x6a/0x90<br /> ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]<br /> ? exc_invalid_op+0x50/0x70<br /> ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]<br /> ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]<br /> btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]<br /> ? __seccomp_filter+0x31d/0x4f0<br /> __x64_sys_fdatasync+0x4f/0x90<br /> do_syscall_64+0x82/0x160<br /> ? do_futex+0xcb/0x190<br /> ? __x64_sys_futex+0x10e/0x1d0<br /> ? switch_fpu_return+0x4f/0xd0<br /> ? syscall_exit_to_user_mode+0x72/0x220<br /> ? do_syscall_64+0x8e/0x160<br /> ? syscall_exit_to_user_mod<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Ensure array index tg_inst won&amp;#39;t be -1<br /> <br /> [WHY &amp; HOW]<br /> tg_inst will be a negative if timing_generator_count equals 0, which<br /> should be checked before used.<br /> <br /> This fixes 2 OVERRUN issues reported by Coverity.

Hidden functionality issue in multiple digital video recorders provided by TAKENAKA ENGINEERING CO., LTD. allows a remote authenticated attacker to execute an arbitrary OS command on the device or alter the device settings.

OMFLOW from The SYSCOM Group has a vulnerability involving the exposure of sensitive data. This allows remote attackers who have logged into the system to obtain password hashes of all users and administrators.