CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49876 – drm/xe: fix UAF around queue destruction
https://notcve.org/view.php?id=CVE-2024-49876
In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/272b0e78874586d6ccae04079d75b27b47705544 https://git.kernel.org/stable/c/421c74670b0f9d5c007f1276d3647aa58f407fde https://git.kernel.org/stable/c/2d2be279f1ca9e7288282d4214f16eea8a727cdb •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49875 – nfsd: map the EBADMSG to nfserr_io to avoid warning
https://notcve.org/view.php?id=CVE-2024-49875
In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? • https://git.kernel.org/stable/c/0ea4333c679f333e23956de743ad17387819d3f2 https://git.kernel.org/stable/c/825789ca94602543101045ad3aad19b2b60c6b2a https://git.kernel.org/stable/c/6fe058502f8864649c3d614b06b2235223798f48 https://git.kernel.org/stable/c/f7d8ee9db94372b8235f5f22bb24381891594c42 https://git.kernel.org/stable/c/c76005adfa93d1a027433331252422078750321f https://git.kernel.org/stable/c/e9cfecca22a36b927a440abc6307efb9e138fed5 https://git.kernel.org/stable/c/340e61e44c1d2a15c42ec72ade9195ad525fd048 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49874 – i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition
https://notcve.org/view.php?id=CVE-2024-49874
In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove. • https://git.kernel.org/stable/c/0f74f8b6675cc36d689abb4d9b3d75ab4049b7d7 https://git.kernel.org/stable/c/4ac637122930cc4ab7e2c22e364cf3aaf96b05b1 https://git.kernel.org/stable/c/4318998892bf8fe99f97bea18c37ae7b685af75a https://git.kernel.org/stable/c/27b55724d3f781dd6e635e89dc6e2fd78fa81a00 https://git.kernel.org/stable/c/61850725779709369c7e907ae8c7c75dc7cec4f3 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49871 – Input: adp5589-keys - fix NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-49871
In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early. • https://git.kernel.org/stable/c/30df385e35a48f773b85117fc490152c2395e45b https://git.kernel.org/stable/c/4449fedb8a710043fc0925409eba844c192d4337 https://git.kernel.org/stable/c/34e304cc53ae5d3c8e3f08b41dd11e0d4f3e01ed https://git.kernel.org/stable/c/7c3f04223aaf82489472d614c6decee5a1ce8d7f https://git.kernel.org/stable/c/9a38791ee79bd17d225c15a6d1479448be127a59 https://git.kernel.org/stable/c/122b160561f6429701a0559a0f39b0ae309488c6 https://git.kernel.org/stable/c/fb5cc65f973661241e4a2b7390b429aa7b330c69 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49870 – cachefiles: fix dentry leak in cachefiles_open_file()
https://notcve.org/view.php?id=CVE-2024-49870
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code. • https://git.kernel.org/stable/c/1f08c925e7a38002bde509e66f6f891468848511 https://git.kernel.org/stable/c/d32ff64c872d7e08e893c32ba6a2374583444410 https://git.kernel.org/stable/c/c7d10fa7d7691558ff967668494672415f5fa151 https://git.kernel.org/stable/c/e4a28489b310339b2b8187bec0a437709be551c1 https://git.kernel.org/stable/c/7fa2382f97421978514a419c93054eca69f5247b https://git.kernel.org/stable/c/da6ef2dffe6056aad3435e6cf7c6471c2a62187c •