CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46686 – smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()
https://notcve.org/view.php?id=CVE-2024-46686
In the Linux kernel, the following vulnerability has been resolved: smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() This happens when called from SMB2_read() while using rdma and reaching the rdma_readwrite_threshold. • https://git.kernel.org/stable/c/edf38e9f4269591d26b3783c0b348c9345580c3c https://git.kernel.org/stable/c/a6559cc1d35d3eeafb0296aca347b2f745a28a74 https://git.kernel.org/stable/c/74ab77137c99438626f4eb8134d8e26204bb5b64 https://git.kernel.org/stable/c/6df57c63c200cd05e085c3b695128260e21959b7 https://git.kernel.org/stable/c/a01859dd6aebf826576513850a3b05992809e9d2 https://git.kernel.org/stable/c/b902fb78ab21299e4dd1775e7e8d251d5c0735bc https://git.kernel.org/stable/c/c724b2ab6a46435b4e7d58ad2fbbdb7a318823cf •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46685 – pinctrl: single: fix potential NULL dereference in pcs_get_function()
https://notcve.org/view.php?id=CVE-2024-46685
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review. • https://git.kernel.org/stable/c/571aec4df5b72a80f80d1e524da8fbd7ff525c98 https://git.kernel.org/stable/c/0a2bab5ed161318f57134716accba0a30f3af191 https://git.kernel.org/stable/c/2cea369a5c2e85ab14ae716da1d1cc6d25c85e11 https://git.kernel.org/stable/c/4e9436375fcc9bd2a60ee96aba6ed53f7a377d10 https://git.kernel.org/stable/c/6341c2856785dca7006820b127278058a180c075 https://git.kernel.org/stable/c/8f0bd526921b6867c2f10a83cd4fd14139adcd92 https://git.kernel.org/stable/c/4ed45fe99ec9e3c9478bd634624cd05a57d002f7 https://git.kernel.org/stable/c/292151af6add3e5ab11b2e9916cffa5f5 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46684 – binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined
https://notcve.org/view.php?id=CVE-2024-46684
In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined create_elf_fdpic_tables() does not correctly account the space for the AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc/<pid>/auxv") it resulted in the last entry of the AUX vector being set to zero, but with that change it results in a kernel BUG. Fix that by adding one to the number of AUXV entries (nitems) when ELF_HWCAP2 is defined. • https://git.kernel.org/stable/c/10e29251be0e9f774910c1baaa89355859491769 https://git.kernel.org/stable/c/c507da85e4f80c630deb9e98222ccf4118cbe6f8 https://git.kernel.org/stable/c/c6a09e342f8e6d3cac7f7c5c14085236aca284b9 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46683 – drm/xe: prevent UAF around preempt fence
https://notcve.org/view.php?id=CVE-2024-46683
In the Linux kernel, the following vulnerability has been resolved: drm/xe: prevent UAF around preempt fence The fence lock is part of the queue, therefore in the current design anything locking the fence should then also hold a ref to the queue to prevent the queue from being freed. However, currently it looks like we signal the fence and then drop the queue ref, but if something is waiting on the fence, the waiter is kicked to wake up at some later point, where upon waking up it first grabs the lock before checking the fence state. But if we have already dropped the queue ref, then the lock might already be freed as part of the queue, leading to uaf. To prevent this, move the fence lock into the fence itself so we don't run into lifetime issues. Alternative might be to have device level lock, or only release the queue in the fence release callback, however that might require pushing to another worker to avoid locking issues. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/10081b0b0ed201f53e24bd92deb2e0f3c3e713d4 https://git.kernel.org/stable/c/730b72480e29f63fd644f5fa57c9d46109428953 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46682 – nfsd: prevent panic for nfsv4.0 closed files in nfs4_show_open
https://notcve.org/view.php?id=CVE-2024-46682
In the Linux kernel, the following vulnerability has been resolved: nfsd: prevent panic for nfsv4.0 closed files in nfs4_show_open Prior to commit 3f29cc82a84c ("nfsd: split sc_status out of sc_type") states_show() relied on sc_type field to be of valid type before calling into a subfunction to show content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0 opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [ 513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178 • https://git.kernel.org/stable/c/3f29cc82a84c23cfd12b903029dd26002ca825f5 https://git.kernel.org/stable/c/ba0b697de298285301c71c258598226e06494236 https://git.kernel.org/stable/c/a204501e1743d695ca2930ed25a2be9f8ced96d3 •