Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures<br /> <br /> Syzkaller reported a hung task with uevent_show() on stack trace. That<br /> specific issue was addressed by another commit [0], but even with that<br /> fix applied (for example, running v6.12-rc5) we face another type of hung<br /> task that comes from the same reproducer [1]. By investigating that, we<br /> could narrow it to the following path:<br /> <br /> (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and<br /> dummy_hcd infrastructure.<br /> <br /> (b) During the probe of rtl8192cu, the driver ends-up performing an efuse<br /> read procedure (which is related to EEPROM load IIUC), and here lies the<br /> issue: the function read_efuse() calls read_efuse_byte() many times, as<br /> loop iterations depending on the efuse size (in our example, 512 in total).<br /> <br /> This procedure for reading efuse bytes relies in a loop that performs an<br /> I/O read up to *10k* times in case of failures. We measured the time of<br /> the loop inside read_efuse_byte() alone, and in this reproducer (which<br /> involves the dummy_hcd emulation layer), it takes 15 seconds each. As a<br /> consequence, we have the driver stuck in its probe routine for big time,<br /> exposing a stack trace like below if we attempt to reboot the system, for<br /> example:<br /> <br /> task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __schedule+0xe22/0xeb6<br /> schedule_timeout+0xe7/0x132<br /> __wait_for_common+0xb5/0x12e<br /> usb_start_wait_urb+0xc5/0x1ef<br /> ? usb_alloc_urb+0x95/0xa4<br /> usb_control_msg+0xff/0x184<br /> _usbctrl_vendorreq_sync+0xa0/0x161<br /> _usb_read_sync+0xb3/0xc5<br /> read_efuse_byte+0x13c/0x146<br /> read_efuse+0x351/0x5f0<br /> efuse_read_all_map+0x42/0x52<br /> rtl_efuse_shadow_map_update+0x60/0xef<br /> rtl_get_hwinfo+0x5d/0x1c2<br /> rtl92cu_read_eeprom_info+0x10a/0x8d5<br /> ? rtl92c_read_chip_version+0x14f/0x17e<br /> rtl_usb_probe+0x323/0x851<br /> usb_probe_interface+0x278/0x34b<br /> really_probe+0x202/0x4a4<br /> __driver_probe_device+0x166/0x1b2<br /> driver_probe_device+0x2f/0xd8<br /> [...]<br /> <br /> We propose hereby to drastically reduce the attempts of doing the I/O<br /> reads in case of failures, restricted to USB devices (given that<br /> they&amp;#39;re inherently slower than PCIe ones). By retrying up to 10 times<br /> (instead of 10000), we got reponsiveness in the reproducer, while seems<br /> reasonable to believe that there&amp;#39;s no sane USB device implementation in<br /> the field requiring this amount of retries at every I/O read in order<br /> to properly work. Based on that assumption, it&amp;#39;d be good to have it<br /> backported to stable but maybe not since driver implementation (the 10k<br /> number comes from day 0), perhaps up to 6.x series makes sense.<br /> <br /> [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")<br /> <br /> [1] A note about that: this syzkaller report presents multiple reproducers<br /> that differs by the type of emulated USB device. For this specific case,<br /> check the entry from 2024/08/08 06:23 in the list of crashes; the C repro<br /> is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: prevent use-after-free due to open_cached_dir error paths<br /> <br /> If open_cached_dir() encounters an error parsing the lease from the<br /> server, the error handling may race with receiving a lease break,<br /> resulting in open_cached_dir() freeing the cfid while the queued work is<br /> pending.<br /> <br /> Update open_cached_dir() to drop refs rather than directly freeing the<br /> cfid.<br /> <br /> Have cached_dir_lease_break(), cfids_laundromat_worker(), and<br /> invalidate_all_cached_dirs() clear has_lease immediately while still<br /> holding cfids-&gt;cfid_list_lock, and then use this to also simplify the<br /> reference counting in cfids_laundromat_worker() and<br /> invalidate_all_cached_dirs().<br /> <br /> Fixes this KASAN splat (which manually injects an error and lease break<br /> in open_cached_dir()):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0<br /> Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65<br /> <br /> CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> Workqueue: cifsiod smb2_cached_lease_break<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x77/0xb0<br /> print_report+0xce/0x660<br /> kasan_report+0xd3/0x110<br /> smb2_cached_lease_break+0x27/0xb0<br /> process_one_work+0x50a/0xc50<br /> worker_thread+0x2ba/0x530<br /> kthread+0x17c/0x1c0<br /> ret_from_fork+0x34/0x60<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 2464:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> open_cached_dir+0xa7d/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 2464:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x51/0x70<br /> kfree+0x174/0x520<br /> open_cached_dir+0x97f/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x33/0x60<br /> __kasan_record_aux_stack+0xad/0xc0<br /> insert_work+0x32/0x100<br /> __queue_work+0x5c9/0x870<br /> queue_work_on+0x82/0x90<br /> open_cached_dir+0x1369/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The buggy address belongs to the object at ffff88811cc24c00<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 16 bytes inside of<br /> freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Don&amp;#39;t leak cfid when reconnect races with open_cached_dir<br /> <br /> open_cached_dir() may either race with the tcon reconnection even before<br /> compound_send_recv() or directly trigger a reconnection via<br /> SMB2_open_init() or SMB_query_info_init().<br /> <br /> The reconnection process invokes invalidate_all_cached_dirs() via<br /> cifs_mark_open_files_invalid(), which removes all cfids from the<br /> cfids-&gt;entries list but doesn&amp;#39;t drop a ref if has_lease isn&amp;#39;t true. This<br /> results in the currently-being-constructed cfid not being on the list,<br /> but still having a refcount of 2. It leaks if returned from<br /> open_cached_dir().<br /> <br /> Fix this by setting cfid-&gt;has_lease when the ref is actually taken; the<br /> cfid will not be used by other threads until it has a valid time.<br /> <br /> Addresses these kmemleaks:<br /> <br /> unreferenced object 0xffff8881090c4000 (size 1024):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 32 bytes):<br /> 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........".......<br /> 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O.....<br /> backtrace (crc 6f58c20f):<br /> [] __kmalloc_cache_noprof+0x2be/0x350<br /> [] open_cached_dir+0x993/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> unreferenced object 0xffff8881044fdcf8 (size 8):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 8 bytes):<br /> 00 cc cc cc cc cc cc cc ........<br /> backtrace (crc 10c106a9):<br /> [] __kmalloc_node_track_caller_noprof+0x363/0x480<br /> [] kstrdup+0x36/0x60<br /> [] open_cached_dir+0x9b0/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> And addresses these BUG splats when unmounting the SMB filesystem:<br /> <br /> BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]<br /> WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:umount_check+0xd0/0x100<br /> Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41<br /> RSP: 0018:ffff88811cc27978 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40<br /> RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3<br /> R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08<br /> R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0<br /> FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> d_walk+0x6a/0x530<br /> shrink_dcache_for_umount+0x6a/0x200<br /> generic_shutdown_super+0x52/0x2a0<br /> kill_anon_super+0x22/0x40<br /> cifs_kill_sb+0x159/0x1e0<br /> deactivate_locked_super+0x66/0xe0<br /> cleanup_mnt+0x140/0x210<br /> task_work_run+0xfb/0x170<br /> syscall_exit_to_user_mode+0x29f/0x2b0<br /> do_syscall_64+0xa1/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f23bfb93ae7<br /> Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free of signing key<br /> <br /> Customers have reported use-after-free in @ses-&gt;auth_key.response with<br /> SMB2.1 + sign mounts which occurs due to following race:<br /> <br /> task A task B<br /> cifs_mount()<br /> dfs_mount_share()<br /> get_session()<br /> cifs_mount_get_session() cifs_send_recv()<br /> cifs_get_smb_ses() compound_send_recv()<br /> cifs_setup_session() smb2_setup_request()<br /> kfree_sensitive() smb2_calc_signature()<br /> crypto_shash_setkey() *UAF*<br /> <br /> Fix this by ensuring that we have a valid @ses-&gt;auth_key.response by<br /> checking whether @ses-&gt;ses_status is SES_GOOD or SES_EXITING with<br /> @ses-&gt;ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF<br /> in smb2_reconnect_server()"), we made sure to call -&gt;logoff() only<br /> when @ses was known to be good (e.g. valid -&gt;auth_key.response), so<br /> it&amp;#39;s safe to access signing key when @ses-&gt;ses_status == SES_EXITING.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "block, bfq: merge bfq_release_process_ref() into bfq_put_cooperator()"<br /> <br /> This reverts commit bc3b1e9e7c50e1de0f573eea3871db61dd4787de.<br /> <br /> The bic is associated with sync_bfqq, and bfq_release_process_ref cannot<br /> be put into bfq_put_cooperator.<br /> <br /> kasan report:<br /> [ 400.347277] ==================================================================<br /> [ 400.347287] BUG: KASAN: slab-use-after-free in bic_set_bfqq+0x200/0x230<br /> [ 400.347420] Read of size 8 at addr ffff88881cab7d60 by task dockerd/5800<br /> [ 400.347430]<br /> [ 400.347436] CPU: 24 UID: 0 PID: 5800 Comm: dockerd Kdump: loaded Tainted: G E 6.12.0 #32<br /> [ 400.347450] Tainted: [E]=UNSIGNED_MODULE<br /> [ 400.347454] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022<br /> [ 400.347460] Call Trace:<br /> [ 400.347464] <br /> [ 400.347468] dump_stack_lvl+0x5d/0x80<br /> [ 400.347490] print_report+0x174/0x505<br /> [ 400.347521] kasan_report+0xe0/0x160<br /> [ 400.347541] bic_set_bfqq+0x200/0x230<br /> [ 400.347549] bfq_bic_update_cgroup+0x419/0x740<br /> [ 400.347560] bfq_bio_merge+0x133/0x320<br /> [ 400.347584] blk_mq_submit_bio+0x1761/0x1e20<br /> [ 400.347625] __submit_bio+0x28b/0x7b0<br /> [ 400.347664] submit_bio_noacct_nocheck+0x6b2/0xd30<br /> [ 400.347690] iomap_readahead+0x50c/0x680<br /> [ 400.347731] read_pages+0x17f/0x9c0<br /> [ 400.347785] page_cache_ra_unbounded+0x366/0x4a0<br /> [ 400.347795] filemap_fault+0x83d/0x2340<br /> [ 400.347819] __xfs_filemap_fault+0x11a/0x7d0 [xfs]<br /> [ 400.349256] __do_fault+0xf1/0x610<br /> [ 400.349270] do_fault+0x977/0x11a0<br /> [ 400.349281] __handle_mm_fault+0x5d1/0x850<br /> [ 400.349314] handle_mm_fault+0x1f8/0x560<br /> [ 400.349324] do_user_addr_fault+0x324/0x970<br /> [ 400.349337] exc_page_fault+0x76/0xf0<br /> [ 400.349350] asm_exc_page_fault+0x26/0x30<br /> [ 400.349360] RIP: 0033:0x55a480d77375<br /> [ 400.349384] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 3b 66 10 0f 86 ae 02 00 00 55 48 89 e5 48 83 ec 58 48 8b 10 7a 10 00 0f 84 27 02 00 00 44 0f b6 42 28 44 0f b6 4a 29 41 80<br /> [ 400.349392] RSP: 002b:00007f18c37fd8b8 EFLAGS: 00010216<br /> [ 400.349401] RAX: 00007f18c37fd9d0 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 400.349407] RDX: 000055a484407d38 RSI: 000000c000e8b0c0 RDI: 0000000000000000<br /> [ 400.349412] RBP: 00007f18c37fd910 R08: 000055a484017f60 R09: 000055a484066f80<br /> [ 400.349417] R10: 0000000000194000 R11: 0000000000000005 R12: 0000000000000008<br /> [ 400.349422] R13: 0000000000000000 R14: 000000c000476a80 R15: 0000000000000000<br /> [ 400.349430] <br /> [ 400.349452]<br /> [ 400.349454] Allocated by task 5800:<br /> [ 400.349459] kasan_save_stack+0x30/0x50<br /> [ 400.349469] kasan_save_track+0x14/0x30<br /> [ 400.349475] __kasan_slab_alloc+0x89/0x90<br /> [ 400.349482] kmem_cache_alloc_node_noprof+0xdc/0x2a0<br /> [ 400.349492] bfq_get_queue+0x1ef/0x1100<br /> [ 400.349502] __bfq_get_bfqq_handle_split+0x11a/0x510<br /> [ 400.349511] bfq_insert_requests+0xf55/0x9030<br /> [ 400.349519] blk_mq_flush_plug_list+0x446/0x14c0<br /> [ 400.349527] __blk_flush_plug+0x27c/0x4e0<br /> [ 400.349534] blk_finish_plug+0x52/0xa0<br /> [ 400.349540] _xfs_buf_ioapply+0x739/0xc30 [xfs]<br /> [ 400.350246] __xfs_buf_submit+0x1b2/0x640 [xfs]<br /> [ 400.350967] xfs_buf_read_map+0x306/0xa20 [xfs]<br /> [ 400.351672] xfs_trans_read_buf_map+0x285/0x7d0 [xfs]<br /> [ 400.352386] xfs_imap_to_bp+0x107/0x270 [xfs]<br /> [ 400.353077] xfs_iget+0x70d/0x1eb0 [xfs]<br /> [ 400.353786] xfs_lookup+0x2ca/0x3a0 [xfs]<br /> [ 400.354506] xfs_vn_lookup+0x14e/0x1a0 [xfs]<br /> [ 400.355197] __lookup_slow+0x19c/0x340<br /> [ 400.355204] lookup_one_unlocked+0xfc/0x120<br /> [ 400.355211] ovl_lookup_single+0x1b3/0xcf0 [overlay]<br /> [ 400.355255] ovl_lookup_layer+0x316/0x490 [overlay]<br /> [ 400.355295] ovl_lookup+0x844/0x1fd0 [overlay]<br /> [ 400.355351] lookup_one_qstr_excl+0xef/0x150<br /> [ 400.355357] do_unlinkat+0x22a/0x620<br /> [ 400.355366] __x64_sys_unlinkat+0x109/0x1e0<br /> [ 400.355375] do_syscall_64+0x82/0x160<br /> [ 400.355384] entry_SYSCALL_64_after_hwframe+0x76/0x7<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix NULL ptr deref in crypto_aead_setkey()<br /> <br /> Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so<br /> when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,<br /> the client uses AES-128-CCM as the default cipher. See MS-SMB2<br /> 3.3.5.4.<br /> <br /> Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added<br /> a @server-&gt;cipher_type check to conditionally call<br /> smb3_crypto_aead_allocate(), but that check would always be false as<br /> @server-&gt;cipher_type is unset for SMB3.02.<br /> <br /> Fix the following KASAN splat by setting @server-&gt;cipher_type for<br /> SMB3.02 as well.<br /> <br /> mount.cifs //srv/share /mnt -o vers=3.02,seal,...<br /> <br /> BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130<br /> Read of size 8 at addr 0000000000000020 by task mount.cifs/1095<br /> CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41<br /> 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> ? crypto_aead_setkey+0x2c/0x130<br /> kasan_report+0xda/0x110<br /> ? crypto_aead_setkey+0x2c/0x130<br /> crypto_aead_setkey+0x2c/0x130<br /> crypt_message+0x258/0xec0 [cifs]<br /> ? __asan_memset+0x23/0x50<br /> ? __pfx_crypt_message+0x10/0x10 [cifs]<br /> ? mark_lock+0xb0/0x6a0<br /> ? hlock_class+0x32/0xb0<br /> ? mark_lock+0xb0/0x6a0<br /> smb3_init_transform_rq+0x352/0x3f0 [cifs]<br /> ? lock_acquire.part.0+0xf4/0x2a0<br /> smb_send_rqst+0x144/0x230 [cifs]<br /> ? __pfx_smb_send_rqst+0x10/0x10 [cifs]<br /> ? hlock_class+0x32/0xb0<br /> ? smb2_setup_request+0x225/0x3a0 [cifs]<br /> ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]<br /> compound_send_recv+0x59b/0x1140 [cifs]<br /> ? __pfx_compound_send_recv+0x10/0x10 [cifs]<br /> ? __create_object+0x5e/0x90<br /> ? hlock_class+0x32/0xb0<br /> ? do_raw_spin_unlock+0x9a/0xf0<br /> cifs_send_recv+0x23/0x30 [cifs]<br /> SMB2_tcon+0x3ec/0xb30 [cifs]<br /> ? __pfx_SMB2_tcon+0x10/0x10 [cifs]<br /> ? lock_acquire.part.0+0xf4/0x2a0<br /> ? __pfx_lock_release+0x10/0x10<br /> ? do_raw_spin_trylock+0xc6/0x120<br /> ? lock_acquire+0x3f/0x90<br /> ? _get_xid+0x16/0xd0 [cifs]<br /> ? __pfx_SMB2_tcon+0x10/0x10 [cifs]<br /> ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]<br /> cifs_get_smb_ses+0xcdd/0x10a0 [cifs]<br /> ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]<br /> ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]<br /> cifs_mount_get_session+0x8a/0x210 [cifs]<br /> dfs_mount_share+0x1b0/0x11d0 [cifs]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_dfs_mount_share+0x10/0x10 [cifs]<br /> ? lock_acquire.part.0+0xf4/0x2a0<br /> ? find_held_lock+0x8a/0xa0<br /> ? hlock_class+0x32/0xb0<br /> ? lock_release+0x203/0x5d0<br /> cifs_mount+0xb3/0x3d0 [cifs]<br /> ? do_raw_spin_trylock+0xc6/0x120<br /> ? __pfx_cifs_mount+0x10/0x10 [cifs]<br /> ? lock_acquire+0x3f/0x90<br /> ? find_nls+0x16/0xa0<br /> ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]<br /> cifs_smb3_do_mount+0x1e2/0xc80 [cifs]<br /> ? __pfx_vfs_parse_fs_string+0x10/0x10<br /> ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]<br /> smb3_get_tree+0x1bf/0x330 [cifs]<br /> vfs_get_tree+0x4a/0x160<br /> path_mount+0x3c1/0xfb0<br /> ? kasan_quarantine_put+0xc7/0x1d0<br /> ? __pfx_path_mount+0x10/0x10<br /> ? kmem_cache_free+0x118/0x3e0<br /> ? user_path_at+0x74/0xa0<br /> __x64_sys_mount+0x1a6/0x1e0<br /> ? __pfx___x64_sys_mount+0x10/0x10<br /> ? mark_held_locks+0x1a/0x90<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Add sanity NULL check for the default mmap fault handler<br /> <br /> A driver might allow the mmap access before initializing its<br /> runtime-&gt;dma_area properly. Add a proper NULL check before passing to<br /> virt_to_page() for avoiding a panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: vector: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the vector_device instance. Otherwise, removing a vector device<br /> will result in a crash:<br /> <br /> RIP: 0033:vector_device_release+0xf/0x50<br /> RSP: 00000000e187bc40 EFLAGS: 00010202<br /> RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0<br /> RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000<br /> RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70<br /> R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028<br /> R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 60028f61 623ae028 e187bc80 60276fcd<br /> 6220b9c0 603f5820 623ae028 00000000<br /> e187bcb0 603a2bcd 623ae000 62370010<br /> Call Trace:<br /> [] ? vector_device_release+0x0/0x50<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xba/0xe7<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] vector_remove+0x52/0x58<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? strlen+0x0/0x15<br /> [] ? __dequeue_entity+0x1a9/0x206<br /> [] ? set_next_entity+0x39/0x63<br /> [] ? set_next_entity+0x0/0x63<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1b3/0x2dd<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x1e9/0x293<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x293<br /> [] kthread+0x126/0x12b<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: net: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the uml_net instance. Otherwise, removing a network device will<br /> result in a crash:<br /> <br /> RIP: 0033:net_device_release+0x10/0x6f<br /> RSP: 00000000e20c7c40 EFLAGS: 00010206<br /> RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0<br /> RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028<br /> RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70<br /> R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000<br /> R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 627af028 62c7af00 e20c7c80 60276fcd<br /> 62778000 603f5820 627af028 00000000<br /> e20c7cb0 603a2bcd 627af000 62770010<br /> Call Trace:<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xba/0xe7<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] net_remove+0x63/0x69<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? __remove_hrtimer+0x38/0x74<br /> [] ? hrtimer_try_to_cancel+0x8c/0x98<br /> [] ? dl_server_stop+0x3f/0x48<br /> [] ? dl_server_stop+0x0/0x48<br /> [] ? dequeue_entities+0x327/0x390<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1b3/0x2dd<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x1e9/0x293<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x293<br /> [] kthread+0x126/0x12b<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: ubd: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the ubd instance. Otherwise, removing a ubd device will result<br /> in a crash:<br /> <br /> RIP: 0033:blk_mq_free_tag_set+0x1f/0xba<br /> RSP: 00000000e2083bf0 EFLAGS: 00010246<br /> RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00<br /> RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348<br /> RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7<br /> R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000<br /> R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 00000000 604f7ef0 62c5d000 62405d20<br /> e2083c30 6002c776 6002c755 600e47ff<br /> e2083c60 6025ffe3 04208060 603d36e0<br /> Call Trace:<br /> [] ubd_device_release+0x21/0x55<br /> [] ? ubd_device_release+0x0/0x55<br /> [] ? kfree+0x0/0x100<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xb5/0xe2<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] ubd_remove+0xb8/0xd6<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? mconsole_reply+0x48/0x50<br /> [] ? um_set_signals+0x3b/0x43<br /> [] ? update_min_vruntime+0x14/0x70<br /> [] ? dequeue_task_fair+0x164/0x235<br /> [] ? update_cfs_group+0x0/0x40<br /> [] ? __schedule+0x0/0x3ed<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1af/0x2c3<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x2f7/0x37a<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x37a<br /> [] kthread+0x130/0x135<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fabrics: fix kernel crash while shutting down controller<br /> <br /> The nvme keep-alive operation, which executes at a periodic interval,<br /> could potentially sneak in while shutting down a fabric controller.<br /> This may lead to a race between the fabric controller admin queue<br /> destroy code path (invoked while shutting down controller) and hw/hctx<br /> queue dispatcher called from the nvme keep-alive async request queuing<br /> operation. This race could lead to the kernel crash shown below:<br /> <br /> Call Trace:<br /> autoremove_wake_function+0x0/0xbc (unreliable)<br /> __blk_mq_sched_dispatch_requests+0x114/0x24c<br /> blk_mq_sched_dispatch_requests+0x44/0x84<br /> blk_mq_run_hw_queue+0x140/0x220<br /> nvme_keep_alive_work+0xc8/0x19c [nvme_core]<br /> process_one_work+0x200/0x4e0<br /> worker_thread+0x340/0x504<br /> kthread+0x138/0x140<br /> start_kernel_thread+0x14/0x18<br /> <br /> While shutting down fabric controller, if nvme keep-alive request sneaks<br /> in then it would be flushed off. The nvme_keep_alive_end_io function is<br /> then invoked to handle the end of the keep-alive operation which<br /> decrements the admin-&gt;q_usage_counter and assuming this is the last/only<br /> request in the admin queue then the admin-&gt;q_usage_counter becomes zero.<br /> If that happens then blk-mq destroy queue operation (blk_mq_destroy_<br /> queue()) which could be potentially running simultaneously on another<br /> cpu (as this is the controller shutdown code path) would forward<br /> progress and deletes the admin queue. So, now from this point onward<br /> we are not supposed to access the admin queue resources. However the<br /> issue here&amp;#39;s that the nvme keep-alive thread running hw/hctx queue<br /> dispatch operation hasn&amp;#39;t yet finished its work and so it could still<br /> potentially access the admin queue resource while the admin queue had<br /> been already deleted and that causes the above crash.<br /> <br /> The above kernel crash is regression caused due to changes implemented<br /> in commit a54a93d0e359 ("nvme: move stopping keep-alive into<br /> nvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroyin<br /> g the admin queue and freeing the admin tagset so that it wouldn&amp;#39;t sneak<br /> in during the shutdown operation. However we removed the keep alive stop<br /> operation from the beginning of the controller shutdown code path in commit<br /> a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()")<br /> and added it under nvme_uninit_ctrl() which executes very late in the<br /> shutdown code path after the admin queue is destroyed and its tagset is<br /> removed. So this change created the possibility of keep-alive sneaking in<br /> and interfering with the shutdown operation and causing observed kernel<br /> crash.<br /> <br /> To fix the observed crash, we decided to move nvme_stop_keep_alive() from<br /> nvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensure<br /> that we don&amp;#39;t forward progress and delete the admin queue until the keep-<br /> alive operation is finished (if it&amp;#39;s in-flight) or cancelled and that would<br /> help contain the race condition explained above and hence avoid the crash.<br /> <br /> Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead of<br /> adding nvme_stop_keep_alive() to the beginning of the controller shutdown<br /> code path in nvme_stop_ctrl(), as was the case earlier before commit<br /> a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"),<br /> would help save one callsite of nvme_stop_keep_alive().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: During unmount, ensure all cached dir instances drop their dentry<br /> <br /> The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can<br /> race with various cached directory operations, which ultimately results<br /> in dentries not being dropped and these kernel BUGs:<br /> <br /> BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]<br /> VFS: Busy inodes after unmount of cifs (cifs)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:661!<br /> <br /> This happens when a cfid is in the process of being cleaned up when, and<br /> has been removed from the cfids-&gt;entries list, including:<br /> <br /> - Receiving a lease break from the server<br /> - Server reconnection triggers invalidate_all_cached_dirs(), which<br /> removes all the cfids from the list<br /> - The laundromat thread decides to expire an old cfid.<br /> <br /> To solve these problems, dropping the dentry is done in queued work done<br /> in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()<br /> flushes that workqueue after it drops all the dentries of which it&amp;#39;s<br /> aware. This is a global workqueue (rather than scoped to a mount), but<br /> the queued work is minimal.<br /> <br /> The final cleanup work for cleaning up a cfid is performed via work<br /> queued in the serverclose_wq workqueue; this is done separate from<br /> dropping the dentries so that close_all_cached_dirs() doesn&amp;#39;t block on<br /> any server operations.<br /> <br /> Both of these queued works expect to invoked with a cfid reference and<br /> a tcon reference to avoid those objects from being freed while the work<br /> is ongoing.<br /> <br /> While we&amp;#39;re here, add proper locking to close_all_cached_dirs(), and<br /> locking around the freeing of cfid-&gt;dentry.