Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()<br /> <br /> name is char[64] where the size of clnt-&gt;cl_program-&gt;name remains<br /> unknown. Invoking strcat() directly will also lead to potential buffer<br /> overflow. Change them to strscpy() and strncat() to fix potential<br /> issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: smc: Handle missing SCM device<br /> <br /> Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer<br /> dereference") makes it explicit that qcom_scm_get_tzmem_pool() can<br /> return NULL, therefore its users should handle this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: bsg: Set bsg_queue to NULL after removal<br /> <br /> Currently, this does not cause any issues, but I believe it is necessary to<br /> set bsg_queue to NULL after removing it to prevent potential use-after-free<br /> (UAF) access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread<br /> <br /> syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]<br /> <br /> If dvb-&gt;mux is not initialized successfully by vidtv_mux_init() in the<br /> vidtv_start_streaming(), it will trigger null pointer dereference about mux<br /> in vidtv_mux_stop_thread().<br /> <br /> Adjust the timing of streaming initialization and check it before<br /> stopping it.<br /> <br /> [1]<br /> KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]<br /> CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471<br /> Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8<br /> RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125<br /> RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128<br /> RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188<br /> R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710<br /> FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]<br /> vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252<br /> dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000<br /> dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486<br /> dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3f8/0xb60 fs/file_table.c:450<br /> task_work_run+0x14e/0x250 kernel/task_work.c:239<br /> get_signal+0x1d3/0x2610 kernel/signal.c:2790<br /> arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218<br /> do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion<br /> <br /> The rtwdev-&gt;scanning flag isn&amp;#39;t protected by mutex originally, so<br /> cancel_hw_scan can pass the condition, but suddenly hw_scan completion<br /> unset the flag and calls ieee80211_scan_completed() that will free<br /> local-&gt;hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and<br /> use-after-free. Fix it by moving the check condition to where<br /> protected by mutex.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]<br /> CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE<br /> Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019<br /> Workqueue: events cfg80211_conn_work [cfg80211]<br /> RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]<br /> Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d<br /> RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001<br /> RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089<br /> RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960<br /> R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? show_regs+0x61/0x73<br /> ? __die_body+0x20/0x73<br /> ? die_addr+0x4f/0x7b<br /> ? exc_general_protection+0x191/0x1db<br /> ? asm_exc_general_protection+0x27/0x30<br /> ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]<br /> ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]<br /> ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]<br /> ? do_raw_spin_lock+0x75/0xdb<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]<br /> ? _raw_spin_unlock+0xe/0x24<br /> ? __mutex_lock.constprop.0+0x40c/0x471<br /> ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]<br /> ? __mutex_lock_slowpath+0x13/0x1f<br /> ? mutex_lock+0xa2/0xdc<br /> ? __pfx_mutex_lock+0x10/0x10<br /> rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]<br /> rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]<br /> ieee80211_scan_cancel+0x468/0x4d0 [mac80211]<br /> ieee80211_prep_connection+0x858/0x899 [mac80211]<br /> ieee80211_mgd_auth+0xbea/0xdde [mac80211]<br /> ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]<br /> ? cfg80211_find_elem+0x15/0x29 [cfg80211]<br /> ? is_bss+0x1b7/0x1d7 [cfg80211]<br /> ieee80211_auth+0x18/0x27 [mac80211]<br /> cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]<br /> cfg80211_conn_do_work+0x410/0xb81 [cfg80211]<br /> ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]<br /> ? __kasan_check_read+0x11/0x1f<br /> ? psi_group_change+0x8bc/0x944<br /> ? __kasan_check_write+0x14/0x22<br /> ? mutex_lock+0x8e/0xdc<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ? __pfx___radix_tree_lookup+0x10/0x10<br /> cfg80211_conn_work+0x245/0x34d [cfg80211]<br /> ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]<br /> ? update_cfs_rq_load_avg+0x3bc/0x3d7<br /> ? sched_clock_noinstr+0x9/0x1a<br /> ? sched_clock+0x10/0x24<br /> ? sched_clock_cpu+0x7e/0x42e<br /> ? newidle_balance+0x796/0x937<br /> ? __pfx_sched_clock_cpu+0x10/0x10<br /> ? __pfx_newidle_balance+0x10/0x10<br /> ? __kasan_check_read+0x11/0x1f<br /> ? psi_group_change+0x8bc/0x944<br /> ? _raw_spin_unlock+0xe/0x24<br /> ? raw_spin_rq_unlock+0x47/0x54<br /> ? raw_spin_rq_unlock_irq+0x9/0x1f<br /> ? finish_task_switch.isra.0+0x347/0x586<br /> ? __schedule+0x27bf/0x2892<br /> ? mutex_unlock+0x80/0xd0<br /> ? do_raw_spin_lock+0x75/0xdb<br /> ? __pfx___schedule+0x10/0x10<br /> process_scheduled_works+0x58c/0x821<br /> worker_thread+0x4c7/0x586<br /> ? __kasan_check_read+0x11/0x1f<br /> kthread+0x285/0x294<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x29/0x6f<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failed<br /> <br /> If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered<br /> without removing the interface first. Then the mgnt_entry list init again,<br /> causing the list_empty() check in rtw89_chanctx_ops_assign_vif()<br /> useless, and list_add_tail() again. Therefore, we have added a check to<br /> prevent double adding of the list.<br /> <br /> rtw89_8852ce 0000:01:00.0: failed to check wow status disabled<br /> rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready<br /> rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw<br /> rtw89_8852ce 0000:01:00.0: failed to disable wow<br /> rtw89_8852ce 0000:01:00.0: failed to resume for wow -110<br /> rtw89_8852ce 0000:01:00.0: MAC has already powered on<br /> i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs<br /> list_add corruption. prev-&gt;next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030).<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:34!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O<br /> Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024<br /> Workqueue: events_unbound async_run_entry_fn<br /> RIP: 0010:__list_add_valid_or_report+0x9f/0xb0<br /> Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ...<br /> RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246<br /> RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400<br /> RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff<br /> RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff<br /> R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40<br /> R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060<br /> FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x68/0xb0<br /> ? die+0xaa/0xd0<br /> ? do_trap+0x9f/0x170<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? handle_invalid_op+0x69/0x90<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]<br /> ? __mutex_unlock_slowpath+0xa0/0xf0<br /> rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]<br /> drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]<br /> ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> ? dev_printk_emit+0x51/0x70<br /> ? _dev_info+0x6e/0x90<br /> wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> dpm_run_callback+0x37/0x1e0<br /> device_resume+0x26d/0x4b0<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x29/0xd0<br /> worker_thread+0x397/0x970<br /> kthread+0xed/0x110<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x38/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()<br /> <br /> Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()<br /> where shifting the constant "1" (of type int) by bitmap-&gt;mapped.pgshift<br /> (an unsigned long value) could result in undefined behavior.<br /> <br /> The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds<br /> 31 (e.g., pgshift = 63) the shift operation overflows, as the result<br /> cannot be represented in a 32-bit type.<br /> <br /> To resolve this, the constant is updated to "1UL", promoting it to an<br /> unsigned long type to match the operand&amp;#39;s type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix oops due to unset link speed<br /> <br /> It isn&amp;#39;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always<br /> be set by the server, so the client must handle any values and then<br /> prevent oopses like below from happening:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41<br /> 04/01/2014<br /> RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48<br /> 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8<br /> e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 f7 74 24 18 48 89<br /> c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24<br /> RSP: 0018:ffffc90001817be0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99<br /> RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228<br /> RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac<br /> R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200<br /> R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58<br /> FS: 00007fe27119e740(0000) GS:ffff888148600000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0x159/0x1b0<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? do_error_trap+0x90/0x130<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? exc_divide_error+0x39/0x50<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? asm_exc_divide_error+0x1a/0x20<br /> ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? seq_read_iter+0x42e/0x790<br /> seq_read_iter+0x19a/0x790<br /> proc_reg_read_iter+0xbe/0x110<br /> ? __pfx_proc_reg_read_iter+0x10/0x10<br /> vfs_read+0x469/0x570<br /> ? do_user_addr_fault+0x398/0x760<br /> ? __pfx_vfs_read+0x10/0x10<br /> ? find_held_lock+0x8a/0xa0<br /> ? __pfx_lock_release+0x10/0x10<br /> ksys_read+0xd3/0x170<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? __rcu_read_unlock+0x50/0x270<br /> ? mark_held_locks+0x1a/0x90<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe271288911<br /> Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8<br /> 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 3d<br /> 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec<br /> RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911<br /> RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003<br /> RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380<br /> R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000<br /> R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000<br /> <br /> <br /> Fix this by setting cifs_server_iface::speed to a sane value (1Gbps)<br /> by default when link speed is unset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: avoid UAF for reorder_work<br /> <br /> Although the previous patch can avoid ps and ps UAF for _do_serial, it<br /> can not avoid potential UAF issue for reorder_work. This issue can<br /> happen just as below:<br /> <br /> crypto_request crypto_request crypto_del_alg<br /> padata_do_serial<br /> ...<br /> padata_reorder<br /> // processes all remaining<br /> // requests then breaks<br /> while (1) {<br /> if (!padata)<br /> break;<br /> ...<br /> }<br /> <br /> padata_do_serial<br /> // new request added<br /> list_add<br /> // sees the new request<br /> queue_work(reorder_work)<br /> padata_reorder<br /> queue_work_on(squeue-&gt;work)<br /> ...<br /> <br /> <br /> padata_serial_worker<br /> // completes new request,<br /> // no more outstanding<br /> // requests<br /> <br /> crypto_del_alg<br /> // free pd<br /> <br /> <br /> invoke_padata_reorder<br /> // UAF of pd<br /> <br /> To avoid UAF for &amp;#39;reorder_work&amp;#39;, get &amp;#39;pd&amp;#39; ref before put &amp;#39;reorder_work&amp;#39;<br /> into the &amp;#39;serial_wq&amp;#39; and put &amp;#39;pd&amp;#39; ref until the &amp;#39;serial_wq&amp;#39; finish.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: fix UAF in padata_reorder<br /> <br /> A bug was found when run ltp test:<br /> <br /> BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0<br /> Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206<br /> <br /> CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+<br /> Workqueue: pdecrypt_parallel padata_parallel_worker<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> print_address_description.constprop.0+0x6b/0x3d0<br /> print_report+0xdd/0x2c0<br /> kasan_report+0xa5/0xd0<br /> padata_find_next+0x29/0x1a0<br /> padata_reorder+0x131/0x220<br /> padata_parallel_worker+0x3d/0xc0<br /> process_one_work+0x2ec/0x5a0<br /> <br /> If &amp;#39;mdelay(10)&amp;#39; is added before calling &amp;#39;padata_find_next&amp;#39; in the<br /> &amp;#39;padata_reorder&amp;#39; function, this issue could be reproduced easily with<br /> ltp test (pcrypt_aead01).<br /> <br /> This can be explained as bellow:<br /> <br /> pcrypt_aead_encrypt<br /> ...<br /> padata_do_parallel<br /> refcount_inc(&amp;pd-&gt;refcnt); // add refcnt<br /> ...<br /> padata_do_serial<br /> padata_reorder // pd<br /> while (1) {<br /> padata_find_next(pd, true); // using pd<br /> queue_work_on<br /> ...<br /> padata_serial_worker crypto_del_alg<br /> padata_put_pd_cnt // sub refcnt<br /> padata_free_shell<br /> padata_put_pd(ps-&gt;pd);<br /> // pd is freed<br /> // loop again, but pd is freed<br /> // call padata_find_next, UAF<br /> }<br /> <br /> In the padata_reorder function, when it loops in &amp;#39;while&amp;#39;, if the alg is<br /> deleted, the refcnt may be decreased to 0 before entering<br /> &amp;#39;padata_find_next&amp;#39;, which leads to UAF.<br /> <br /> As mentioned in [1], do_serial is supposed to be called with BHs disabled<br /> and always happen under RCU protection, to address this issue, add<br /> synchronize_rcu() in &amp;#39;padata_free_shell&amp;#39; wait for all _do_serial calls<br /> to finish.<br /> <br /> [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/<br /> [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Send signals asynchronously if !preemptible<br /> <br /> BPF programs can execute in all kinds of contexts and when a program<br /> running in a non-preemptible context uses the bpf_send_signal() kfunc,<br /> it will cause issues because this kfunc can sleep.<br /> Change `irqs_disabled()` to `!preemptible()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: don&amp;#39;t allow reconnect after disconnect<br /> <br /> Following process can cause nbd_config UAF:<br /> <br /> 1) grab nbd_config temporarily;<br /> <br /> 2) nbd_genl_disconnect() flush all recv_work() and release the<br /> initial reference:<br /> <br /> nbd_genl_disconnect<br /> nbd_disconnect_and_put<br /> nbd_disconnect<br /> flush_workqueue(nbd-&gt;recv_workq)<br /> if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))<br /> nbd_config_put<br /> -&gt; due to step 1), reference is still not zero<br /> <br /> 3) nbd_genl_reconfigure() queue recv_work() again;<br /> <br /> nbd_genl_reconfigure<br /> config = nbd_get_config_unlocked(nbd)<br /> if (!config)<br /> -&gt; succeed<br /> if (!test_bit(NBD_RT_BOUND, ...))<br /> -&gt; succeed<br /> nbd_reconnect_socket<br /> queue_work(nbd-&gt;recv_workq, &amp;args-&gt;work)<br /> <br /> 4) step 1) release the reference;<br /> <br /> 5) Finially, recv_work() will trigger UAF:<br /> <br /> recv_work<br /> nbd_config_put(nbd)<br /> -&gt; nbd_config is freed<br /> atomic_dec(&amp;config-&gt;recv_threads)<br /> -&gt; UAF<br /> <br /> Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so<br /> that nbd_genl_reconfigure() will fail.