Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Update log-&gt;page_{mask,bits} if log-&gt;page_size changed<br /> <br /> If an NTFS file system is mounted to another system with different<br /> PAGE_SIZE from the original system, log-&gt;page_size will change in<br /> log_replay(), but log-&gt;page_{mask,bits} don&amp;#39;t change correspondingly.<br /> This will cause a panic because "u32 bytes = log-&gt;page_size - page_off"<br /> will get a negative value in the later read_log_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dev/parport: fix the array out-of-bounds risk<br /> <br /> Fixed array out-of-bounds issues caused by sprintf<br /> by replacing it with snprintf for safer data copying,<br /> ensuring the destination buffer is not overflowed.<br /> <br /> Below is the stack trace I encountered during the actual issue:<br /> <br /> [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:<br /> Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]<br /> [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:<br /> QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2<br /> [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp<br /> [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun<br /> PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024<br /> [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:<br /> [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0<br /> [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20<br /> [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c<br /> [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc<br /> [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38<br /> [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal<br /> <br /> Keith reports a use-after-free when a DPC event occurs concurrently to<br /> hot-removal of the same portion of the hierarchy:<br /> <br /> The dpc_handler() awaits readiness of the secondary bus below the<br /> Downstream Port where the DPC event occurred. To do so, it polls the<br /> config space of the first child device on the secondary bus. If that<br /> child device is concurrently removed, accesses to its struct pci_dev<br /> cause the kernel to oops.<br /> <br /> That&amp;#39;s because pci_bridge_wait_for_secondary_bus() neglects to hold a<br /> reference on the child device. Before v6.3, the function was only<br /> called on resume from system sleep or on runtime resume. Holding a<br /> reference wasn&amp;#39;t necessary back then because the pciehp IRQ thread<br /> could never run concurrently. (On resume from system sleep, IRQs are<br /> not enabled until after the resume_noirq phase. And runtime resume is<br /> always awaited before a PCI device is removed.)<br /> <br /> However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also<br /> called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness<br /> of secondary bus after reset"), which introduced that, failed to<br /> appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a<br /> reference on the child device because dpc_handler() and pciehp may<br /> indeed run concurrently. The commit was backported to v5.10+ stable<br /> kernels, so that&amp;#39;s the oldest one affected.<br /> <br /> Add the missing reference acquisition.<br /> <br /> Abridged stack trace:<br /> <br /> BUG: unable to handle page fault for address: 00000000091400c0<br /> CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0<br /> RIP: pci_bus_read_config_dword+0x17/0x50<br /> pci_dev_wait()<br /> pci_bridge_wait_for_secondary_bus()<br /> dpc_reset_link()<br /> pcie_do_recovery()<br /> dpc_handler()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: make sure the first directory block is not a hole<br /> <br /> The syzbot constructs a directory that has no dirblock but is non-inline,<br /> i.e. the first directory block is a hole. And no errors are reported when<br /> creating files in this directory in the following flow.<br /> <br /> ext4_mknod<br /> ...<br /> ext4_add_entry<br /> // Read block 0<br /> ext4_read_dirblock(dir, block, DIRENT)<br /> bh = ext4_bread(NULL, inode, block, 0)<br /> if (!bh &amp;&amp; (type == INDEX || type == DIRENT_HTREE))<br /> // The first directory block is a hole<br /> // But type == DIRENT, so no error is reported.<br /> <br /> After that, we get a directory block without &amp;#39;.&amp;#39; and &amp;#39;..&amp;#39; but with a valid<br /> dentry. This may cause some code that relies on dot or dotdot (such as<br /> make_indexed_dir()) to crash.<br /> <br /> Therefore when ext4_read_dirblock() finds that the first directory block<br /> is a hole report that the filesystem is corrupted and return an error to<br /> avoid loading corrupted data from disk causing something bad.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: check dot and dotdot of dx_root before making dir indexed<br /> <br /> Syzbot reports a issue as follows:<br /> ============================================<br /> BUG: unable to handle page fault for address: ffffed11022e24fe<br /> PGD 23ffee067 P4D 23ffee067 PUD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0<br /> Call Trace:<br /> <br /> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341<br /> ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451<br /> ext4_rename fs/ext4/namei.c:3936 [inline]<br /> ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214<br /> [...]<br /> ============================================<br /> <br /> The immediate cause of this problem is that there is only one valid dentry<br /> for the block to be split during do_split, so split==0 results in out of<br /> bounds accesses to the map triggering the issue.<br /> <br /> do_split<br /> unsigned split<br /> dx_make_map<br /> count = 1<br /> split = count/2 = 0;<br /> continued = hash2 == map[split - 1].hash;<br /> ---&gt; map[4294967295]<br /> <br /> The maximum length of a filename is 255 and the minimum block size is 1024,<br /> so it is always guaranteed that the number of entries is greater than or<br /> equal to 2 when do_split() is called.<br /> <br /> But syzbot&amp;#39;s crafted image has no dot and dotdot in dir, and the dentry<br /> distribution in dirblock is as follows:<br /> <br /> bus dentry1 hole dentry2 free<br /> |xx--|xx-------------|...............|xx-------------|...............|<br /> 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024<br /> <br /> So when renaming dentry1 increases its name_len length by 1, neither hole<br /> nor free is sufficient to hold the new dentry, and make_indexed_dir() is<br /> called.<br /> <br /> In make_indexed_dir() it is assumed that the first two entries of the<br /> dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root<br /> because they are treated as dot and dotdot, and only dentry2 is moved<br /> to the new leaf block. That&amp;#39;s why count is equal to 1.<br /> <br /> Therefore add the ext4_check_dx_root() helper function to add more sanity<br /> checks to dot and dotdot before starting the conversion to avoid the above<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Avoid using corrupted block bitmap buffer<br /> <br /> When the filesystem block bitmap is corrupted, we detect the corruption<br /> while loading the bitmap and fail the allocation with error. However the<br /> next allocation from the same bitmap will notice the bitmap buffer is<br /> already loaded and tries to allocate from the bitmap with mixed results<br /> (depending on the exact nature of the bitmap corruption). Fix the<br /> problem by using BH_verified bit to indicate whether the bitmap is valid<br /> or not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path<br /> <br /> Dan Carpenter reported a Smack static checker warning:<br /> fs/smb/client/cifsfs.c:1981 init_cifs()<br /> error: we previously assumed &amp;#39;serverclose_wq&amp;#39; could be null (see line 1895)<br /> <br /> The patch which introduced the serverclose workqueue used the wrong<br /> oredering in error paths in init_cifs() for freeing it on errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes<br /> <br /> In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mediatek: Fix potential NULL pointer dereference in dummy net_device handling<br /> <br /> Move the freeing of the dummy net_device from mtk_free_dev() to<br /> mtk_remove().<br /> <br /> Previously, if alloc_netdev_dummy() failed in mtk_probe(),<br /> eth-&gt;dummy_dev would be NULL. The error path would then call<br /> mtk_free_dev(), which in turn called free_netdev() assuming dummy_dev<br /> was allocated (but it was not), potentially causing a NULL pointer<br /> dereference.<br /> <br /> By moving free_netdev() to mtk_remove(), we ensure it&amp;#39;s only called when<br /> mtk_probe() has succeeded and dummy_dev is fully allocated. This<br /> addresses a potential NULL pointer dereference detected by Smatch[1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: Fix lockless walks with static and dynamic page-table folding<br /> <br /> Lina reports random oopsen originating from the fast GUP code when<br /> 16K pages are used with 4-level page-tables, the fourth level being<br /> folded at runtime due to lack of LPA2.<br /> <br /> In this configuration, the generic implementation of<br /> p4d_offset_lockless() will return a &amp;#39;p4d_t *&amp;#39; corresponding to the<br /> &amp;#39;pgd_t&amp;#39; allocated on the stack of the caller, gup_fast_pgd_range().<br /> This is normally fine, but when the fourth level of page-table is folded<br /> at runtime, pud_offset_lockless() will offset from the address of the<br /> &amp;#39;p4d_t&amp;#39; to calculate the address of the PUD in the same page-table page.<br /> This results in a stray stack read when the &amp;#39;p4d_t&amp;#39; has been allocated<br /> on the stack and can send the walker into the weeds.<br /> <br /> Fix the problem by providing our own definition of p4d_offset_lockless()<br /> when CONFIG_PGTABLE_LEVELS

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix deadlock between sd_remove &amp; sd_release<br /> <br /> Our test report the following hung task:<br /> <br /> [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds.<br /> [ 2538.459427] Call trace:<br /> [ 2538.459430] __switch_to+0x174/0x338<br /> [ 2538.459436] __schedule+0x628/0x9c4<br /> [ 2538.459442] schedule+0x7c/0xe8<br /> [ 2538.459447] schedule_preempt_disabled+0x24/0x40<br /> [ 2538.459453] __mutex_lock+0x3ec/0xf04<br /> [ 2538.459456] __mutex_lock_slowpath+0x14/0x24<br /> [ 2538.459459] mutex_lock+0x30/0xd8<br /> [ 2538.459462] del_gendisk+0xdc/0x350<br /> [ 2538.459466] sd_remove+0x30/0x60<br /> [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4<br /> [ 2538.459474] device_release_driver+0x18/0x28<br /> [ 2538.459478] bus_remove_device+0x15c/0x174<br /> [ 2538.459483] device_del+0x1d0/0x358<br /> [ 2538.459488] __scsi_remove_device+0xa8/0x198<br /> [ 2538.459493] scsi_forget_host+0x50/0x70<br /> [ 2538.459497] scsi_remove_host+0x80/0x180<br /> [ 2538.459502] usb_stor_disconnect+0x68/0xf4<br /> [ 2538.459506] usb_unbind_interface+0xd4/0x280<br /> [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4<br /> [ 2538.459514] device_release_driver+0x18/0x28<br /> [ 2538.459518] bus_remove_device+0x15c/0x174<br /> [ 2538.459523] device_del+0x1d0/0x358<br /> [ 2538.459528] usb_disable_device+0x84/0x194<br /> [ 2538.459532] usb_disconnect+0xec/0x300<br /> [ 2538.459537] hub_event+0xb80/0x1870<br /> [ 2538.459541] process_scheduled_works+0x248/0x4dc<br /> [ 2538.459545] worker_thread+0x244/0x334<br /> [ 2538.459549] kthread+0x114/0x1bc<br /> <br /> [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds.<br /> [ 2538.461014] Call trace:<br /> [ 2538.461016] __switch_to+0x174/0x338<br /> [ 2538.461021] __schedule+0x628/0x9c4<br /> [ 2538.461025] schedule+0x7c/0xe8<br /> [ 2538.461030] blk_queue_enter+0xc4/0x160<br /> [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4<br /> [ 2538.461037] scsi_execute_cmd+0x7c/0x23c<br /> [ 2538.461040] ioctl_internal_command+0x5c/0x164<br /> [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0<br /> [ 2538.461051] sd_release+0x50/0x94<br /> [ 2538.461054] blkdev_put+0x190/0x28c<br /> [ 2538.461058] blkdev_release+0x28/0x40<br /> [ 2538.461063] __fput+0xf8/0x2a8<br /> [ 2538.461066] __fput_sync+0x28/0x5c<br /> [ 2538.461070] __arm64_sys_close+0x84/0xe8<br /> [ 2538.461073] invoke_syscall+0x58/0x114<br /> [ 2538.461078] el0_svc_common+0xac/0xe0<br /> [ 2538.461082] do_el0_svc+0x1c/0x28<br /> [ 2538.461087] el0_svc+0x38/0x68<br /> [ 2538.461090] el0t_64_sync_handler+0x68/0xbc<br /> [ 2538.461093] el0t_64_sync+0x1a8/0x1ac<br /> <br /> T1: T2:<br /> sd_remove<br /> del_gendisk<br /> __blk_mark_disk_dead<br /> blk_freeze_queue_start<br /> ++q-&gt;mq_freeze_depth<br /> bdev_release<br /> mutex_lock(&amp;disk-&gt;open_mutex)<br /> sd_release<br /> scsi_execute_cmd<br /> blk_queue_enter<br /> wait_event(!q-&gt;mq_freeze_depth)<br /> mutex_lock(&amp;disk-&gt;open_mutex)<br /> <br /> SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in<br /> this scenario. This is a classic ABBA deadlock. To fix the deadlock,<br /> make sure we don&amp;#39;t try to acquire disk-&gt;open_mutex after freezing<br /> the queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a segment issue when downgrading gso_size<br /> <br /> Linearize the skb when downgrading gso_size because it may trigger a<br /> BUG_ON() later when the skb is segmented as described in [1,2].