CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52458 – block: add check that partition length needs to be aligned with block size
https://notcve.org/view.php?id=CVE-2023-52458
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: agregar verifique que la longitud de la partición debe estar alineada con el tamaño del bloque Antes de llamar a agregar partición o cambiar el tamaño de la partición, no se verifica si la longitud está alineada con el tamaño del bloque lógico. Si el tamaño del bloque lógico del disco es mayor que 512 bytes, entonces el tamaño de la partición tal vez no sea el múltiplo del tamaño del bloque lógico, y cuando se lea el último sector, bio_truncate() ajustará el tamaño de la biografía, lo que resultará en un error de E/S si el tamaño del comando de lectura es menor que el tamaño del bloque lógico. Si se admiten datos de integridad, esto también resultará en una desreferencia del puntero nulo al llamar a bio_integrity_free. A flaw was found in the Linux kernel's block subsystem, where a NULL pointer dereference occurs if partitions are created or resized with a size that is not a multiple of the logical block size. • https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62 https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503 https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8 https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8 https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5 https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2023 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52457 – serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
https://notcve.org/view.php?id=CVE-2023-52457
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: 8250: omap: no omita la liberación de recursos si pm_runtime_resume_and_get() falla. • https://git.kernel.org/stable/c/2d66412563ef8953e2bac2d98d2d832b3f3f49cd https://git.kernel.org/stable/c/d833cba201adf9237168e19f0d76e4d7aa69f303 https://git.kernel.org/stable/c/e0db709a58bdeb8966890882261a3f8438c5c9b7 https://git.kernel.org/stable/c/e3f0c638f428fd66b5871154b62706772045f91a https://git.kernel.org/stable/c/02eed6390dbe61115f3e3f63829c95c611aee67b https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93 https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0 https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52456 – serial: imx: fix tx statemachine deadlock
https://notcve.org/view.php?id=CVE-2023-52456
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND. • https://git.kernel.org/stable/c/cb1a609236096c278ecbfb7be678a693a70283f1 https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19 https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06 https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181 https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-667: Improper Locking •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52455 – iommu: Don't reserve 0-length IOVA region
https://notcve.org/view.php?id=CVE-2023-52455
In the Linux kernel, the following vulnerability has been resolved: iommu: Don't reserve 0-length IOVA region When the bootloader/firmware doesn't setup the framebuffers, their address and size are 0 in "iommu-addresses" property. If IOVA region is reserved with 0 length, then it ends up corrupting the IOVA rbtree with an entry which has pfn_hi < pfn_lo. If we intend to use display driver in kernel without framebuffer then it's causing the display IOMMU mappings to fail as entire valid IOVA space is reserved when address and length are passed as 0. An ideal solution would be firmware removing the "iommu-addresses" property and corresponding "memory-region" if display is not present. But the kernel should be able to handle this by checking for size of IOVA region and skipping the IOVA reservation if size is 0. Also, add a warning if firmware is requesting 0-length IOVA region reservation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: no reservar región IOVA de longitud 0 Cuando el gestor de arranque/firmware no configura los framebuffers, su dirección y tamaño son 0 en la propiedad "iommu-addresses". Si la región IOVA está reservada con una longitud de 0, termina corrompiendo el rbtree de IOVA con una entrada que tiene pfn_hi < pfn_lo. • https://git.kernel.org/stable/c/a5bf3cfce8cb77d9d24613ab52d520896f83dd48 https://git.kernel.org/stable/c/98b8a550da83cc392a14298c4b3eaaf0332ae6ad https://git.kernel.org/stable/c/5e23e283910c9f30248732ae0770bcb0c9438abf https://git.kernel.org/stable/c/bb57f6705960bebeb832142ce9abf43220c3eab1 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52454 – nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
https://notcve.org/view.php?id=CVE-2023-52454
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmet-tcp: soluciona un pánico del kernel cuando el host envía una longitud de PDU H2C no válida. Si el host envía un comando H2CData con un DATAL no válido, el kernel puede fallar en nvmet_tcp_build_pdu_iovec(). No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 lr: nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Rastreo de llamadas: Process_one_work+0x174/0x3c8 trabajador_thread+0x2d0/0x3e8 kthread+0x104/0x110 Solucione el error generando un error fatal si DATAL es No es coherente con el tamaño del paquete. Además, la longitud de la PDU nunca debe exceder el parámetro MAXH2CDATA que se ha comunicado al host en nvmet_tcp_handle_icreq(). • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510 https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42 https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88 https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68 https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a74 • CWE-476: NULL Pointer Dereference •