CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52761 – riscv: VMAP_STACK overflow detection thread-safe
https://notcve.org/view.php?id=CVE-2023-52761
In the Linux kernel, the following vulnerability has been resolved: riscv: VMAP_STACK overflow detection thread-safe commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to `shadow_stack` temporarily before switching finally to per-cpu `overflow_stack`. If two CPUs/harts are racing and end up in over flowing kernel stack, one or both will end up corrupting each other state because `shadow_stack` is not per-cpu. This patch optimizes per-cpu overflow stack switch by directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`. Following are the changes in this patch - Defines an asm macro to obtain per-cpu symbols in destination register. - In entry.S, when overflow is detected, per-cpu overflow stack is located using per-cpu asm macro. Computing per-cpu symbol requires a temporary register. x31 is saved away into CSR_SCRATCH (CSR_SCRATCH is anyways zero since we're in kernel). Please see Links for additional relevant disccussion and alternative solution. Tested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT` Kernel crash log below Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT Task stack: [0xff20000010a98000..0xff20000010a9c000] Overflow stack: [0xff600001f7d98370..0xff600001f7d99370] CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) epc : __memset+0x60/0xfc ra : recursive_loop+0x48/0xc6 [lkdtm] epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80 gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88 t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0 s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000 a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000 a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90 s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684 s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10 s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4 t5 : ffffffff815dbab8 t6 : ff20000010a9bb48 status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f Kernel panic - not syncing: Kernel stack overflow CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff80006754>] dump_backtrace+0x30/0x38 [<ffffffff808de798>] show_stack+0x40/0x4c [<ffffffff808ea2a8>] dump_stack_lvl+0x44/0x5c [<ffffffff808ea2d8>] dump_stack+0x18/0x20 [<ffffffff808dec06>] panic+0x126/0x2fe [<ffffffff800065ea>] walk_stackframe+0x0/0xf0 [<ffffffff0163a752>] recursive_loop+0x48/0xc6 [lkdtm] SMP: stopping secondary CPUs ---[ end Kernel panic - not syncing: Kernel stack overflow ]--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: detección de desbordamiento de VMAP_STACK confirmación segura para subprocesos 31da94c25aea ("riscv: agregar detección de desbordamiento de VMAP_STACK") se agregó soporte para CONFIG_VMAP_STACK. • https://git.kernel.org/stable/c/1493baaf09e3c1899959c8a107cd1207e16d1788 https://git.kernel.org/stable/c/eff53aea3855f71992c043cebb1c00988c17ee20 https://git.kernel.org/stable/c/be97d0db5f44c0674480cb79ac6f5b0529b84c76 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52760 – gfs2: Fix slab-use-after-free in gfs2_qd_dealloc
https://notcve.org/view.php?id=CVE-2023-52760
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige slab-use-after-free en gfs2_qd_dealloc. En gfs2_put_super(), ya sea retirada o no, gfs2_quota_cleanup() debe limpiar la cuota. De lo contrario, la estructura gfs2_sbd se liberará antes de que se ejecute gfs2_qd_dealloc (devolución de llamada de rcu) para todos los objetos gfs2_quota_data, lo que dará como resultado un use after free. Además, gfs2_destroy_threads() y gfs2_quota_cleanup() ya son llamados por gfs2_make_fs_ro(), por lo que en gfs2_put_super(), después de llamar a gfs2_make_fs_ro(), no es necesario volver a llamarlos. • https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81 https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52759 – gfs2: ignore negated quota changes
https://notcve.org/view.php?id=CVE-2023-52759
In the Linux kernel, the following vulnerability has been resolved: gfs2: ignore negated quota changes When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. • https://git.kernel.org/stable/c/1c28dace66015b675a343b89b0c87abbfda05ff4 https://git.kernel.org/stable/c/b4deec69fe32b58dc5fb4ace52456ece85b75561 https://git.kernel.org/stable/c/2bb42a27a92ff3984c9fa5fbe128eced3ea693f2 https://git.kernel.org/stable/c/2a054b87a1b799b391e578597a42ee6e57a987ae https://git.kernel.org/stable/c/5bfda356e903633d16ae1bac1ee38364e12628a3 https://git.kernel.org/stable/c/53fc16c1ad84f5467ec24341670b63aa759335d3 https://git.kernel.org/stable/c/212f112fe5e90e98eb8d48585682880dae139f4c https://git.kernel.org/stable/c/119565e566f91ff3588ffcd5812f0c806 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52757 – smb: client: fix potential deadlock when releasing mids
https://notcve.org/view.php?id=CVE-2023-52757
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when releasing mids All release_mid() callers seem to hold a reference of @mid so there is no need to call kref_put(&mid->refcount, __release_mid) under @server->mid_lock spinlock. If they don't, then an use-after-free bug would have occurred anyways. By getting rid of such spinlock also fixes a potential deadlock as shown below CPU 0 CPU 1 ------------------------------------------------------------------ cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock* En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: corrige un posible punto muerto al liberar mids. Todos los llamadores de release_mid() parecen tener una referencia de @mid, por lo que no hay necesidad de llamar a kref_put(&mid->refcount, __release_mid ) en @servidor->mid_lock spinlock. Si no lo hacen, de todos modos se habría producido un error de use after free. Al deshacerse de dicho bloqueo de giro, también se soluciona un posible punto muerto como se muestra a continuación CPU 0 CPU 1 -------------------------------- ---------------------------------- cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&servidor->mid_lock) ; spin_lock(&cifs_tcp_ses_lock) spin_lock(&servidor->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *punto muerto* • https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29 https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26 https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7 •
CVSS: 9.0EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52755 – ksmbd: fix slab out of bounds write in smb_inherit_dacl()
https://notcve.org/view.php?id=CVE-2023-52755
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab out of bounds write in smb_inherit_dacl() slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige la escritura fuera de los límites de slab en smb_inherit_dacl(). La escritura fuera de los límites de slab se debe a que las compensaciones son mayores que el tamaño de asignación de pntsd. Este parche agrega la verificación para validar 3 compensaciones usando el tamaño de asignación. • https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819 https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70 https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb • CWE-787: Out-of-bounds Write •