Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: init bioset in mddev_init<br /> <br /> IO operations may be needed before md_run(), such as updating metadata<br /> after writing sysfs. Without bioset, this triggers a NULL pointer<br /> dereference as below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> Call Trace:<br /> md_update_sb+0x658/0xe00<br /> new_level_store+0xc5/0x120<br /> md_attr_store+0xc9/0x1e0<br /> sysfs_kf_write+0x6f/0xa0<br /> kernfs_fop_write_iter+0x141/0x2a0<br /> vfs_write+0x1fc/0x5a0<br /> ksys_write+0x79/0x180<br /> __x64_sys_write+0x1d/0x30<br /> x64_sys_call+0x2818/0x2880<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Reproducer<br /> ```<br /> mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]<br /> echo inactive &gt; /sys/block/md0/md/array_state<br /> echo 10 &gt; /sys/block/md0/md/new_level<br /> ```<br /> <br /> mddev_init() can only be called once per mddev, no need to test if bioset<br /> has been initialized anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc: add the handle of the event to the path<br /> <br /> The handle is essential for retrieving the AUX_EVENT of each CPU and is<br /> required in perf mode. It has been added to the coresight_path so that<br /> dependent devices can access it from the path when needed.<br /> <br /> The existing bug can be reproduced with:<br /> perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null<br /> <br /> Showing an oops as follows:<br /> Unable to handle kernel paging request at virtual address 000f6e84934ed19e<br /> <br /> Call trace:<br /> tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P)<br /> catu_enable_hw+0xbc/0x3d0 [coresight_catu]<br /> catu_enable+0x70/0xe0 [coresight_catu]<br /> coresight_enable_path+0xb0/0x258 [coresight]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: avoid repeated calls to del_gendisk<br /> <br /> There is a uaf problem which is found by case 23rdev-lifetime:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdead000000000122<br /> RIP: 0010:bdi_unregister+0x4b/0x170<br /> Call Trace:<br /> <br /> __del_gendisk+0x356/0x3e0<br /> mddev_unlock+0x351/0x360<br /> rdev_attr_store+0x217/0x280<br /> kernfs_fop_write_iter+0x14a/0x210<br /> vfs_write+0x29e/0x550<br /> ksys_write+0x74/0xf0<br /> do_syscall_64+0xbb/0x380<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff5250a177e<br /> <br /> The sequence is:<br /> 1. rdev remove path gets reconfig_mutex<br /> 2. rdev remove path release reconfig_mutex in mddev_unlock<br /> 3. md stop calls do_md_stop and sets MD_DELETED<br /> 4. rdev remove path calls del_gendisk because MD_DELETED is set<br /> 5. md stop path release reconfig_mutex and calls del_gendisk again<br /> <br /> So there is a race condition we should resolve. This patch adds a<br /> flag MD_DO_DELETE to avoid the race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix rcu protection in md_wakeup_thread<br /> <br /> We attempted to use RCU to protect the pointer &amp;#39;thread&amp;#39;, but directly<br /> passed the value when calling md_wakeup_thread(). This means that the<br /> RCU pointer has been acquired before rcu_read_lock(), which renders<br /> rcu_read_lock() ineffective and could lead to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Fix device resources accessed after device removal<br /> <br /> Correct possible race conditions during device removal.<br /> <br /> Previously, a scheduled work item to reset a LUN could still execute<br /> after the device was removed, leading to use-after-free and other<br /> resource access issues.<br /> <br /> This race condition occurs because the abort handler may schedule a LUN<br /> reset concurrently with device removal via sdev_destroy(), leading to<br /> use-after-free and improper access to freed resources.<br /> <br /> - Check in the device reset handler if the device is still present in<br /> the controller&amp;#39;s SCSI device list before running; if not, the reset<br /> is skipped.<br /> <br /> - Cancel any pending TMF work that has not started in sdev_destroy().<br /> <br /> - Ensure device freeing in sdev_destroy() is done while holding the<br /> LUN reset mutex to avoid races with ongoing resets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: defer config unlock in nbd_genl_connect<br /> <br /> There is one use-after-free warning when running NBD_CMD_CONNECT and<br /> NBD_CLEAR_SOCK:<br /> <br /> nbd_genl_connect<br /> nbd_alloc_and_init_config // config_refs=1<br /> nbd_start_device // config_refs=2<br /> set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3<br /> recv_work done // config_refs=2<br /> NBD_CLEAR_SOCK // config_refs=1<br /> close nbd // config_refs=0<br /> refcount_inc -&gt; uaf<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290<br /> nbd_genl_connect+0x16d0/0x1ab0<br /> genl_family_rcv_msg_doit+0x1f3/0x310<br /> genl_rcv_msg+0x44a/0x790<br /> <br /> The issue can be easily reproduced by adding a small delay before<br /> refcount_inc(&amp;nbd-&gt;config_refs) in nbd_genl_connect():<br /> <br /> mutex_unlock(&amp;nbd-&gt;config_lock);<br /> if (!ret) {<br /> set_bit(NBD_RT_HAS_CONFIG_REF, &amp;config-&gt;runtime_flags);<br /> + printk("before sleep\n");<br /> + mdelay(5 * 1000);<br /> + printk("after sleep\n");<br /> refcount_inc(&amp;nbd-&gt;config_refs);<br /> nbd_connect_reply(info, nbd-&gt;index);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse<br /> <br /> The following warning appears when running syzkaller, and this issue also<br /> exists in the mainline code.<br /> <br /> ------------[ cut here ]------------<br /> list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.<br /> WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130<br /> Modules linked in:<br /> CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__list_add_valid_or_report+0xf7/0x130<br /> RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817<br /> RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001<br /> RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c<br /> R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100<br /> R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48<br /> FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 80000000<br /> Call Trace:<br /> <br /> input_register_handler+0xb3/0x210<br /> mac_hid_start_emulation+0x1c5/0x290<br /> mac_hid_toggle_emumouse+0x20a/0x240<br /> proc_sys_call_handler+0x4c2/0x6e0<br /> new_sync_write+0x1b1/0x2d0<br /> vfs_write+0x709/0x950<br /> ksys_write+0x12a/0x250<br /> do_syscall_64+0x5a/0x110<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The WARNING occurs when two processes concurrently write to the mac-hid<br /> emulation sysctl, causing a race condition in mac_hid_toggle_emumouse().<br /> Both processes read old_val=0, then both try to register the input handler,<br /> leading to a double list_add of the same handler.<br /> <br /> CPU0 CPU1<br /> ------------------------- -------------------------<br /> vfs_write() //write 1 vfs_write() //write 1<br /> proc_sys_write() proc_sys_write()<br /> mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()<br /> old_val = *valp // old_val=0<br /> old_val = *valp // old_val=0<br /> mutex_lock_killable()<br /> proc_dointvec() // *valp=1<br /> mac_hid_start_emulation()<br /> input_register_handler()<br /> mutex_unlock()<br /> mutex_lock_killable()<br /> proc_dointvec()<br /> mac_hid_start_emulation()<br /> input_register_handler() //Trigger Warning<br /> mutex_unlock()<br /> <br /> Fix this by moving the old_val read inside the mutex lock region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: init run lock for extend inode<br /> <br /> After setting the inode mode of $Extend to a regular file, executing the<br /> truncate system call will enter the do_truncate() routine, causing the<br /> run_lock uninitialized error reported by syzbot.<br /> <br /> Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to<br /> a regular file, the do_truncate() routine would not be entered.<br /> <br /> Add the run_lock initialization when loading $Extend.<br /> <br /> syzbot reported:<br /> INFO: trying to register non-static key.<br /> Call Trace:<br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984<br /> register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299<br /> __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112<br /> lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868<br /> down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590<br /> ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860<br /> ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387<br /> ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: defer config put in recv_work<br /> <br /> There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and<br /> NBD_CMD_RECONFIGURE:<br /> nbd_genl_connect // conf_ref=2 (connect and recv_work A)<br /> nbd_open // conf_ref=3<br /> recv_work A done // conf_ref=2<br /> NBD_CLEAR_SOCK // conf_ref=1<br /> nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)<br /> close nbd // conf_ref=1<br /> recv_work B<br /> config_put // conf_ref=0<br /> atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF<br /> <br /> Or only running NBD_CLEAR_SOCK:<br /> nbd_genl_connect // conf_ref=2<br /> nbd_open // conf_ref=3<br /> NBD_CLEAR_SOCK // conf_ref=2<br /> close nbd<br /> nbd_release<br /> config_put // conf_ref=1<br /> recv_work<br /> config_put // conf_ref=0<br /> atomic_dec(&amp;config-&gt;recv_threads); -&gt; UAF<br /> <br /> Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the<br /> waiter") moved nbd_config_put() to run before waking up the waiter in<br /> recv_work, in order to ensure that nbd_start_device_ioctl() would not<br /> be woken up while nbd-&gt;task_recv was still uncleared.<br /> <br /> However, in nbd_start_device_ioctl(), after being woken up it explicitly<br /> calls flush_workqueue() to make sure all current works are finished.<br /> Therefore, there is no need to move the config put ahead of the wakeup.<br /> <br /> Move nbd_config_put() to the end of recv_work, so that the reference is<br /> held for the whole lifetime of the worker thread. This makes sure the<br /> config cannot be freed while recv_work is still running, even if clear<br /> + reconfigure interleave.<br /> <br /> In addition, we don&amp;#39;t need to worry about recv_work dropping the last<br /> nbd_put (which causes deadlock):<br /> <br /> path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):<br /> connect // nbd_refs=1 (trigger recv_work)<br /> open nbd // nbd_refs=2<br /> NBD_CLEAR_SOCK<br /> close nbd<br /> nbd_release<br /> nbd_disconnect_and_put<br /> flush_workqueue // recv_work done<br /> nbd_config_put<br /> nbd_put // nbd_refs=1<br /> nbd_put // nbd_refs=0<br /> queue_work<br /> <br /> path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):<br /> connect // nbd_refs=2 (trigger recv_work)<br /> open nbd // nbd_refs=3<br /> NBD_CLEAR_SOCK // conf_refs=2<br /> close nbd<br /> nbd_release<br /> nbd_config_put // conf_refs=1<br /> nbd_put // nbd_refs=2<br /> recv_work done // conf_refs=0, nbd_refs=1<br /> rmmod // nbd_refs=0<br /> <br /> Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Initialize allocated memory before use<br /> <br /> KMSAN reports: Multiple uninitialized values detected:<br /> <br /> - KMSAN: uninit-value in ntfs_read_hdr (3)<br /> - KMSAN: uninit-value in bcmp (3)<br /> <br /> Memory is allocated by __getname(), which is a wrapper for<br /> kmem_cache_alloc(). This memory is used before being properly<br /> cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to<br /> properly allocate and clear memory before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free of qgroup record after failure to add delayed ref head<br /> <br /> In the previous code it was possible to incur into a double kfree()<br /> scenario when calling add_delayed_ref_head(). This could happen if the<br /> record was reported to already exist in the<br /> btrfs_qgroup_trace_extent_nolock() call, but then there was an error<br /> later on add_delayed_ref_head(). In this case, since<br /> add_delayed_ref_head() returned an error, the caller went to free the<br /> record. Since add_delayed_ref_head() couldn&amp;#39;t set this kfree&amp;#39;d pointer<br /> to NULL, then kfree() would have acted on a non-NULL &amp;#39;record&amp;#39; object<br /> which was pointing to memory already freed by the callee.<br /> <br /> The problem comes from the fact that the responsibility to kfree the<br /> object is on both the caller and the callee at the same time. Hence, the<br /> fix for this is to shift the ownership of the &amp;#39;qrecord&amp;#39; object out of<br /> the add_delayed_ref_head(). That is, we will never attempt to kfree()<br /> the given object inside of this function, and will expect the caller to<br /> act on the &amp;#39;qrecord&amp;#39; object on its own. The only exception where the<br /> &amp;#39;qrecord&amp;#39; object cannot be kfree&amp;#39;d is if it was inserted into the<br /> tracing logic, for which we already have the &amp;#39;qrecord_inserted_ret&amp;#39;<br /> boolean to account for this. Hence, the caller has to kfree the object<br /> only if add_delayed_ref_head() reports not to have inserted it on the<br /> tracing logic.<br /> <br /> As a side-effect of the above, we must guarantee that<br /> &amp;#39;qrecord_inserted_ret&amp;#39; is properly initialized at the start of the<br /> function, not at the end, and then set when an actual insert<br /> happens. This way we avoid &amp;#39;qrecord_inserted_ret&amp;#39; having an invalid<br /> value on an early exit.<br /> <br /> The documentation from the add_delayed_ref_head() has also been updated<br /> to reflect on the exact ownership of the &amp;#39;qrecord&amp;#39; object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks<br /> <br /> MT7996 driver can use both wed and wed_hif2 devices to offload traffic<br /> from/to the wireless NIC. In the current codebase we assume to always<br /> use the primary wed device in wed callbacks resulting in the following<br /> crash if the hw runs wed_hif2 (e.g. 6GHz link).<br /> <br /> [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a<br /> [ 297.464928] Mem abort info:<br /> [ 297.467722] ESR = 0x0000000096000005<br /> [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 297.476766] SET = 0, FnV = 0<br /> [ 297.479809] EA = 0, S1PTW = 0<br /> [ 297.482940] FSC = 0x05: level 1 translation fault<br /> [ 297.487809] Data abort info:<br /> [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000<br /> [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000<br /> [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0<br /> [ 297.723908] Tainted: [O]=OOT_MODULE<br /> [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT)<br /> [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table]<br /> [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76]<br /> [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80<br /> [ 297.757126] sp : ffffffc080fe3ae0<br /> [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7<br /> [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00<br /> [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018<br /> [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000<br /> [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000<br /> [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da<br /> [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200<br /> [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002<br /> [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8<br /> [ 297.831686] Call trace:<br /> [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76]<br /> [ 297.839254] mtk_wed_flow_remove+0x58/0x80<br /> [ 297.843342] mtk_flow_offload_cmd+0x434/0x574<br /> [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40<br /> [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table]<br /> [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table]<br /> [ 297.864463] process_one_work+0x174/0x300<br /> [ 297.868465] worker_thread+0x278/0x430<br /> [ 297.872204] kthread+0xd8/0xdc<br /> [ 297.875251] ret_from_fork+0x10/0x20<br /> [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421)<br /> [ 297.884901] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix the issue detecting the proper wed reference to use running wed<br /> callabacks.