Page 580 of 3446 results (0.020 seconds)

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

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: 0

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: 0

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 &lt; 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 https://access.redhat.com/security/cve/CVE-2023-52455 https://bugzilla.redhat.com/show_bug.cgi?id=2265793 •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume When the optional PRE_COPY support was added to speed up the device compatibility check, it failed to update the saving/resuming data pointers based on the fd offset. This results in migration data corruption and when the device gets started on the destination the following error is reported in some cases, [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010 [ 478.919603] arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000007f [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hisi_acc_vfio_pci: actualiza correctamente el puntero de datos de migración al guardar/reanudar Cuando se agregó el soporte PRE_COPY opcional para acelerar la verificación de compatibilidad del dispositivo, no se pudieron actualizar los punteros de datos de guardado/reanudación según el desplazamiento fd. Esto da como resultado la corrupción de los datos de migración y cuando el dispositivo se inicia en el destino, en algunos casos se informa el siguiente error, [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010 [ 478.919603] arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000007f [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2 • https://git.kernel.org/stable/c/d9a871e4a143047d1d84a606772af319f11516f9 https://git.kernel.org/stable/c/45f80b2f230df10600e6fa1b83b28bf1c334185e https://git.kernel.org/stable/c/6bda81e24a35a856f58e6a5786de579b07371603 https://git.kernel.org/stable/c/be12ad45e15b5ee0e2526a50266ba1d295d26a88 •