CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52789 – tty: vcc: Add check for kstrdup() in vcc_probe()
https://notcve.org/view.php?id=CVE-2023-52789
In the Linux kernel, the following vulnerability has been resolved: tty: vcc: Add check for kstrdup() in vcc_probe() Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: vcc: Agregar verificación para kstrdup() en vcc_probe(). Agregar verificación para el valor de retorno de kstrdup() y devolver el error, si falla, para evitar la desreferencia de puntero NULL . • https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3 https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200 https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06 https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2 https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9 https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52788 – i915/perf: Fix NULL deref bugs with drm_dbg() calls
https://notcve.org/view.php?id=CVE-2023-52788
In the Linux kernel, the following vulnerability has been resolved: i915/perf: Fix NULL deref bugs with drm_dbg() calls When i915 perf interface is not available dereferencing it will lead to NULL dereferences. As returning -ENOTSUPP is pretty clear return when perf interface is not available. [tursulin: added stable tag] (cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i915/perf: corrige errores de desreferencia NULL con llamadas drm_dbg(). Cuando la interfaz i915 perf no está disponible, la desreferenciación conducirá a desreferencias NULL. Como devolver -ENOTSUPP es un retorno bastante claro cuando la interfaz perf no está disponible. [tursulin: etiqueta estable agregada] (cereza seleccionada del compromiso 36f27350ff745bd228ab04d7845dfbffc177a889) • https://git.kernel.org/stable/c/9b344cf6aea0a69c00e19efdc6e02c6d5aae1a23 https://git.kernel.org/stable/c/2fec539112e89255b6a47f566e21d99937fada7b https://git.kernel.org/stable/c/1566e8be73fd5fa424e88d2a4cffdc34f970f0e1 https://git.kernel.org/stable/c/55db76caa782baa4a1bf02296e2773c38a524a3e https://git.kernel.org/stable/c/bf8e105030083e7b71591cdf437e464bcd8a0c09 https://git.kernel.org/stable/c/10f49cdfd5fb342a1a9641930dc040c570694e98 https://git.kernel.org/stable/c/471aa951bf1206d3c10d0daa67005b8e4db4ff83 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52787 – blk-mq: make sure active queue usage is held for bio_integrity_prep()
https://notcve.org/view.php?id=CVE-2023-52787
In the Linux kernel, the following vulnerability has been resolved: blk-mq: make sure active queue usage is held for bio_integrity_prep() blk_integrity_unregister() can come if queue usage counter isn't held for one bio with integrity prepared, so this request may be completed with calling profile->complete_fn, then kernel panic. Another constraint is that bio_integrity_prep() needs to be called before bio merge. Fix the issue by: - call bio_integrity_prep() with one queue usage counter grabbed reliably - call bio_integrity_prep() before bio merge En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: asegúrese de que el uso de la cola activa se mantenga para bio_integrity_prep() blk_integrity_unregister() puede aparecer si el contador de uso de la cola no se mantiene para una biografía con integridad preparada, por lo que esta solicitud se puede completar llamando al perfil->complete_fn, luego kernel panic. Otra restricción es que es necesario llamar a bio_integrity_prep() antes de la fusión biológica. Solucione el problema de la siguiente manera: - llame a bio_integrity_prep() con un contador de uso de cola capturado de manera confiable - llame a bio_integrity_prep() antes de fusionar la biografía • https://git.kernel.org/stable/c/900e080752025f0016128f07c9ed4c50eba3654b https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9 https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78 https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52786 – ext4: fix racy may inline data check in dio write
https://notcve.org/view.php?id=CVE-2023-52786
In the Linux kernel, the following vulnerability has been resolved: ext4: fix racy may inline data check in dio write syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below: if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data. The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds. The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige la verificación de datos en línea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmación a la que se hace referencia a continuación: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en línea. • https://git.kernel.org/stable/c/310ee0902b8d9d0a13a5a13e94688a5863fa29c2 https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52785 – scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR
https://notcve.org/view.php?id=CVE-2023-52785
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR If command timeout happens and cq complete IRQ is raised at the same time, ufshcd_mcq_abort clears lprb->cmd and a NULL pointer deref happens in the ISR. Error log: ufshcd_abort: Device abort task at tag 18 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 pc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: soluciona el problema de ejecuciones entre ufshcd_mcq_abort() e ISR. Si se agota el tiempo de espera del comando y se genera cq complete IRQ al mismo tiempo, ufshcd_mcq_abort borra lprb->cmd y un La eliminación del puntero NULL ocurre en el ISR. Registro de errores: ufshcd_abort: tarea de cancelación del dispositivo en la etiqueta 18 No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000108 pc: [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr: [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24 /0x114 • https://git.kernel.org/stable/c/f1304d4420777f82a1d844c606db3d9eca841765 https://git.kernel.org/stable/c/8f15a7e3c054d960bbd1521110700450bbf798a1 https://git.kernel.org/stable/c/f84d461f33a6b27304d468d9cfb56c0cefdb4ee7 https://git.kernel.org/stable/c/27900d7119c464b43cd9eac69c85884d17bae240 •