CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53181 – um: vector: Do not use drvdata in release
https://notcve.org/view.php?id=CVE-2024-53181
In the Linux kernel, the following vulnerability has been resolved: um: vector: Do not use drvdata in release The drvdata is not available in release. Let's just use container_of() to get the vector_device instance. Otherwise, removing a vector device will result in a crash: RIP: 0033:vector_device_release+0xf/0x50 RSP: 00000000e187bc40 EFLAGS: 00010202 RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 60028f61 623ae028 e187bc80 60276fcd 6220b9c0 603f5820 623ae028 00000000 e187bcb0 603a2bcd 623ae000 62370010 Call Trace: [<60028f61>] ? vector_device_release+0x0/0x50 [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<60029422>] vector_remove+0x52/0x58 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<603b19f4>] ? • https://git.kernel.org/stable/c/8ed7793f6f589b4e1f0b38f8448578d2a48f9c82 https://git.kernel.org/stable/c/376c7f0beb8f6f3800fc3013ef2f422d0cbfbf92 https://git.kernel.org/stable/c/35f8f72b45791a6a71b81140c59d02a6183b6f3b https://git.kernel.org/stable/c/bef9a2835011668c221851a7572b6c8433087f85 https://git.kernel.org/stable/c/dc5251b1af5c9a0749322bf58bd5aa673f545fe2 https://git.kernel.org/stable/c/8204dd589c4f25a7618eece5da3f0871e02af8ae https://git.kernel.org/stable/c/e9d36f7e71a907ec507f84ee5d60a622c345cac4 https://git.kernel.org/stable/c/12f52e373d63f008ee386f371bdd82a3a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-53180 – ALSA: pcm: Add sanity NULL check for the default mmap fault handler
https://notcve.org/view.php?id=CVE-2024-53180
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Add sanity NULL check for the default mmap fault handler A driver might allow the mmap access before initializing its runtime->dma_area properly. Add a proper NULL check before passing to virt_to_page() for avoiding a panic. • https://git.kernel.org/stable/c/8799f4332a9fd812eadfbc32fc5104d6292f754f https://git.kernel.org/stable/c/832efbb74b1578e3737d593a204d42af8bd1b81b https://git.kernel.org/stable/c/bc200027ee92fba84f1826494735ed675f3aa911 https://git.kernel.org/stable/c/f0ce9e24eff1678c16276f9717f26a78202506a2 https://git.kernel.org/stable/c/0c4c9bf5eab7bee6b606f2abb0993e933b5831a0 https://git.kernel.org/stable/c/d2913a07d9037fe7aed4b7e680684163eaed6bc4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53179 – smb: client: fix use-after-free of signing key
https://notcve.org/view.php?id=CVE-2024-53179
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free of signing key Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. • https://git.kernel.org/stable/c/0e2b654a3848bf9da3b0d54c1ccf3f1b8c635591 https://git.kernel.org/stable/c/343d7fe6df9e247671440a932b6a73af4fa86d95 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53177 – smb: prevent use-after-free due to open_cached_dir error paths
https://notcve.org/view.php?id=CVE-2024-53177
In the Linux kernel, the following vulnerability has been resolved: smb: prevent use-after-free due to open_cached_dir error paths If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) • https://git.kernel.org/stable/c/791f833053578b9fd24252ebb7162a61bc3f805b https://git.kernel.org/stable/c/97e2afcac0bebfef6a5360f4267ce4c44507b845 https://git.kernel.org/stable/c/47655a12c6b1bca8fa230085eab2e85a076932b7 https://git.kernel.org/stable/c/a9685b409a03b73d2980bbfa53eb47555802d0a9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53174 – SUNRPC: make sure cache entry active before cache_show
https://notcve.org/view.php?id=CVE-2024-53174
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: make sure cache entry active before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e • https://git.kernel.org/stable/c/e9be26735d055c42543a4d047a769cc6d0fb1504 https://git.kernel.org/stable/c/02999e135b013d85c6df738746e8e24699befee4 https://git.kernel.org/stable/c/c7dac3af57e38b2054f990e573256d90bf887958 https://git.kernel.org/stable/c/068c0b50f3f700b94f78850834cd91ae3b34c2c1 https://git.kernel.org/stable/c/acfaf37888e0f0732fb6a50ff093dce6d99994d0 https://git.kernel.org/stable/c/ec305f303bf070b4f6896b7a76009f702956d402 https://git.kernel.org/stable/c/d882e2b7fad3f5e5fac66184a347f408813f654a https://git.kernel.org/stable/c/2862eee078a4d2d1f584e7f24fa50dddf •