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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53173 – NFSv4.0: Fix a use-after-free problem in the asynchronous open()
https://notcve.org/view.php?id=CVE-2024-53173
In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed. • https://git.kernel.org/stable/c/24ac23ab88df5b21b5b2df8cde748bf99b289099 https://git.kernel.org/stable/c/1cfae9575296f5040cdc84b0730e79078c081d2d https://git.kernel.org/stable/c/7bf6bf130af8ee7d93a99c28a7512df3017ec759 https://git.kernel.org/stable/c/5237a297ffd374a1c4157a53543b7a69d7bbbc03 https://git.kernel.org/stable/c/2ab9639f16b05d948066a6c4cf19a0fdc61046ff https://git.kernel.org/stable/c/ba6e6c04f60fe52d91520ac4d749d372d4c74521 https://git.kernel.org/stable/c/229a30ed42bb87bcb044c5523fabd9e4f0e75648 https://git.kernel.org/stable/c/e2277a1d9d5cd0d625a4fd7c04fce2b53 •