CVSS: 6.2EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52765 – mfd: qcom-spmi-pmic: Fix revid implementation
https://notcve.org/view.php?id=CVE-2023-52765
In the Linux kernel, the following vulnerability has been resolved: mfd: qcom-spmi-pmic: Fix revid implementation The Qualcomm SPMI PMIC revid implementation is broken in multiple ways. First, it assumes that just because the sibling base device has been registered that means that it is also bound to a driver, which may not be the case (e.g. due to probe deferral or asynchronous probe). This could trigger a NULL-pointer dereference when attempting to access the driver data of the unbound device. Second, it accesses driver data of a sibling device directly and without any locking, which means that the driver data may be freed while it is being accessed (e.g. on driver unbind). Third, it leaks a struct device reference to the sibling device which is looked up using the spmi_device_from_of() every time a function (child) device is calling the revid function (e.g. on probe). Fix this mess by reimplementing the revid lookup so that it is done only at probe of the PMIC device; the base device fetches the revid info from the hardware, while any secondary SPMI device fetches the information from the base device and caches it so that it can be accessed safely from its children. If the base device has not been probed yet then probe of a secondary device is deferred. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mfd: qcom-spmi-pmic: reparación de la implementación revid. La implementación revid de Qualcomm SPMI PMIC está rota de varias maneras. • https://git.kernel.org/stable/c/e9c11c6e3a0e93903f5a13f8d2f97ae1bba512e1 https://git.kernel.org/stable/c/db98de0809f12b0edb9cd1be78e1ec1bfeba8f40 https://git.kernel.org/stable/c/4ce77b023d42a9f1062eecf438df1af4b4072eb2 https://git.kernel.org/stable/c/affae18838db5e6b463ee30c821385695af56dc2 https://git.kernel.org/stable/c/7b439aaa62fee474a0d84d67a25f4984467e7b95 • CWE-476: NULL Pointer Dereference •
CVSS: 4.4EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52764 – media: gspca: cpia1: shift-out-of-bounds in set_flicker
https://notcve.org/view.php?id=CVE-2023-52764
In the Linux kernel, the following vulnerability has been resolved: media: gspca: cpia1: shift-out-of-bounds in set_flicker Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int' When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: gspca: cpia1: desplazamiento fuera de los límites en set_flicker. Syzkaller informó el siguiente problema: UBSAN: desplazamiento fuera de los límites en drivers/media/usb/gspca /cpia1.c:1031:27 el exponente de desplazamiento 245 es demasiado grande para el tipo 'int' de 32 bits. • https://git.kernel.org/stable/c/69bba62600bd91d6b7c1e8ca181faf8ac64f7060 https://git.kernel.org/stable/c/2eee8edfff90e22980a6b22079d238c3c9d323bb https://git.kernel.org/stable/c/8f83c85ee88225319c52680792320c02158c2a9b https://git.kernel.org/stable/c/c6b6b8692218da73b33b310d7c1df90f115bdd9a https://git.kernel.org/stable/c/09cd8b561aa9796903710a1046957f2b112c8f26 https://git.kernel.org/stable/c/a647f27a7426d2fe1b40da7c8fa2b81354a51177 https://git.kernel.org/stable/c/93bddd6529f187f510eec759f37d0569243c9809 https://git.kernel.org/stable/c/e2d7149b913d14352c82624e723ce1c21 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52763 – i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data.
https://notcve.org/view.php?id=CVE-2023-52763
In the Linux kernel, the following vulnerability has been resolved: i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data. The `i3c_master_bus_init` function may attach the I2C devices before the I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used before the DAT `init`. Additionally, if the `i3c_master_bus_init` fails, the DAT `cleanup` will execute before the device is detached, which will execue DAT `free_entry` function. The above scenario can cause the driver to use DAT_data when it is NULL. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i3c: master: mipi-i3c-hci: se corrigió un pánico del kernel al acceder a DAT_data. • https://git.kernel.org/stable/c/39c71357e68e2f03766f9321b9f4882e49ff1442 https://git.kernel.org/stable/c/e64d23dc65810be4e3395d72df0c398f60c991f9 https://git.kernel.org/stable/c/3cb79a365e7cce8f121bba91312e2ddd206b9781 https://git.kernel.org/stable/c/eed74230435c61eeb58abaa275b1820e6a4b7f02 https://git.kernel.org/stable/c/b53e9758a31c683fc8615df930262192ed5f034b •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52762 – virtio-blk: fix implicit overflow on virtio_max_dma_size
https://notcve.org/view.php?id=CVE-2023-52762
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: fix implicit overflow on virtio_max_dma_size The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: virtio-blk: corrige el desbordamiento implícito en virtio_max_dma_size. Los siguientes códigos tienen una conversión implícita de size_t a u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); Esto puede provocar un desbordamiento, Ex (size_t)4G -> (u32)0. Una vez que virtio_max_dma_size() tenga un tamaño mayor que U32_MAX, use U32_MAX en su lugar. • https://git.kernel.org/stable/c/72775cad7f572bb2501f9ea609e1d20e68f0b38b https://git.kernel.org/stable/c/472bd4787406bef2e8b41ee4c74d960a06a49a48 https://git.kernel.org/stable/c/017278f141141367f7d14b203e930b45b6ffffb9 https://git.kernel.org/stable/c/d667fe301dcbcb12d1d6494fc4b8abee2cb75d90 https://git.kernel.org/stable/c/fafb51a67fb883eb2dde352539df939a251851be https://access.redhat.com/security/cve/CVE-2023-52762 https://bugzilla.redhat.com/show_bug.cgi?id=2282623 • CWE-121: Stack-based Buffer Overflow •
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 •