Page 388 of 2870 results (0.006 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: Reparar pérdida de memoria en __qlt_24xx_handle_abts() el commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") hizo que la función __qlt_24xx_handle_abts() regresara antes si tcm_qla2xxx_find_cmd_by_tag() no lo hizo encontró un comando, pero no pudo limpiar la memoria asignada para el comando de administración. • https://git.kernel.org/stable/c/8f394da36a361cbe0e1e8b1d4213e5598c8095ac https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82 https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7 https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf •

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

In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corrige la desreferencia del puntero nulo en efx_hard_start_xmit Intentar obtener el canal de la variable tx_queue aquí es incorrecto porque solo podemos estar aquí si tx_queue es NULL, por lo que no debemos desreferenciarlo. Como dice el comentario anterior en el código, es muy poco probable que esto suceda, pero de todos modos está mal, así que solucionémoslo. Encontré este problema debido a un error diferente que provocó que tx_queue fuera NULL. • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7 https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998 https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03 https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3 •

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

In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: corrige el desplazamiento del canal TX cuando se usan interrupciones heredadas En el modo de interrupción heredado, tx_channel_offset estaba codificado en 1, pero eso no es correcto si efx_sepparate_tx_channels es falso. En ese caso, el desplazamiento es 0 porque las colas de transmisión están en el único canal existente en el índice 0, junto con la cola de recepción. Sin esta solución, tan pronto como intenta enviar tráfico, intenta obtener las colas de transmisión de un canal no inicializado y obtiene estos errores: ADVERTENCIA: CPU: 1 PID: 0 en drivers/net/ethernet/sfc/tx.c: 540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] • https://git.kernel.org/stable/c/bf2af9b24313553f3f0b30443220ab0ac8595d2d https://git.kernel.org/stable/c/06cb7e134f8f4a11b66f1dbeb5f237412a0aeedc https://git.kernel.org/stable/c/c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2 https://git.kernel.org/stable/c/1a7c0b3ef93d1d1dae7b0a85dab3ac6e3ad0ef61 https://git.kernel.org/stable/c/b2d60329a0b88c4e35017436ee29c43be59d46a5 https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e •

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

In the Linux kernel, the following vulnerability has been resolved: sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc/siena: corrige la desreferencia del puntero nulo en efx_hard_start_xmit Al igual que en el parche anterior para sfc, evita una posible (pero poco probable) desreferencia del puntero NULL. • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: denegar la descarga de funciones TSN basadas en tc en interfaces VF Las funciones TSN en ENETC (taprio, cbs, gate, policial) se configuran mediante una combinación de comandos BD ring mensajes y registros de puertos: enetc_port_rd(), enetc_port_wr(). Los registros de puerto son una región del mapa de memoria ENETC a la que solo se puede acceder desde la función física PCIe. • https://git.kernel.org/stable/c/34c6adf1977b611fca3b824ad12a2a415e1e420e https://git.kernel.org/stable/c/510e703e4ed0e011db860bc21228aff48fc9eea7 https://git.kernel.org/stable/c/23022b74b1a23bed044f6bc96cf92f6ca5f3e75f https://git.kernel.org/stable/c/5641c751fe2f92d3d9e8a8e03c1263ac8caa0b42 •