Page 274 of 2616 results (0.017 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: thermal/debugfs: Prevent use-after-free from occurring after cdev removal Since thermal_debug_cdev_remove() does not run under cdev->lock, it can run in parallel with thermal_debug_cdev_state_update() and it may free the struct thermal_debugfs object used by the latter after it has been checked against NULL. If that happens, thermal_debug_cdev_state_update() will access memory that has been freed already causing the kernel to crash. Address this by using cdev->lock in thermal_debug_cdev_remove() around the cdev->debugfs value check (in case the same cdev is removed at the same time in two different threads) and its reset to NULL. Cc :6.8+ <stable@vger.kernel.org> # 6.8+ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/debugfs: evita que se produzca use after free después de la eliminación de cdev. Dado que Thermal_debug_cdev_remove() no se ejecuta bajo cdev-&gt;lock, puede ejecutarse en paralelo con Thermal_debug_cdev_state_update() y puede liberar el objeto struct Thermal_debugfs utilizado por este último después de haberlo verificado con NULL. Si eso sucede, Thermal_debug_cdev_state_update() accederá a la memoria que ya ha sido liberada, lo que provocará que el kernel falle. Solucione esto usando cdev-&gt;lock en Thermal_debug_cdev_remove() alrededor de la verificación del valor de cdev-&gt;debugfs (en caso de que el mismo cdev se elimine al mismo tiempo en dos subprocesos diferentes) y se restablezca a NULL. CC :6.8+ # 6.8+ • https://git.kernel.org/stable/c/755113d7678681a137c330f7997ceb680adb644e https://git.kernel.org/stable/c/c1279dee33369e2525f532364bb87207d23b9481 https://git.kernel.org/stable/c/d351eb0ab04c3e8109895fc33250cebbce9c11da • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: s390/cio: Ensure the copied buf is NUL terminated Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdup_user_nul instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/cio: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de lbuf y copiamos lbuf del espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/a4f17cc726712a52122ad38540bc3ff3a052d1a4 https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5 https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2 https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65 https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784 •

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

In the Linux kernel, the following vulnerability has been resolved: spi: fix null pointer dereference within spi_sync If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message(). With function inlining disabled, the call stack might look like this: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28 Fix this by also setting message->complete to NULL when the transfer is complete. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: corrige la desreferencia del puntero nulo dentro de spi_sync Si se llama a spi_sync() con la cola no vacía y luego se reutiliza el mismo spi_message, la devolución de llamada completa para el mensaje permanece configurada mientras el el contexto se borra, lo que lleva a una desreferencia del puntero nulo cuando se invoca la devolución de llamada desde spi_finalize_current_message(). Con la función incorporada deshabilitada, la pila de llamadas podría verse así: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2 a8/0x474 spi_transfer_one_message de __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message de __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue de __spi_sync+0x204/0x248 __spi_sync de spi_sync+0x24/0x3c spi_sync de mcp251xfd_regmap_crc_read+0x124/0x28c fd] mcp251xfd_regmap_crc_read [mcp251xfd] de _regmap_raw_read+0xf8/0x154 _regmap_raw_read de _regmap_bus_read+0x44/0x70 _regmap_bus_read de _regmap_read+ 0x60/0xd8 _regmap_read de regmap_read+0x3c/0x5c regmap_read de mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] de mcp251xfd_irq+0x19 4/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] de irq_thread_fn+0x1c/0x78 irq_thread_fn de irq_thread+0x118/0x1f4 irq_thread de kthread+0xd8/0xf4 kthread de ret_from_fork+0x14/0x28 Solucione este problema configurando también mensaje-&gt;completo en NULL cuando se complete la transferencia. • https://git.kernel.org/stable/c/ae7d2346dc89ae89a6e0aabe6037591a11e593c0 https://git.kernel.org/stable/c/e005d6754e3e440257006795b687c4ad8733b493 https://git.kernel.org/stable/c/a30659f1576d2c8e62e7426232bb18b885fd951a https://git.kernel.org/stable/c/2070d008cc08bff50a58f0f4d30f12d3ebf94c00 https://git.kernel.org/stable/c/4756fa529b2f12b7cb8f21fe229b0f6f47190829 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: net: core: reject skb_copy(_expand) for fraglist GSO skbs SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: core: rechazar skb_copy(_expand) para fraglist GSO skbs Los skbs SKB_GSO_FRAGLIST no deben linealizarse; de lo contrario, dejarán de ser válidos. Devuelve NULL si dicho skb se pasa a skb_copy o skb_copy_expand, para evitar un bloqueo en una posible llamada posterior a skb_gso_segment. • https://git.kernel.org/stable/c/3a1296a38d0cf62bffb9a03c585cbd5dbf15d596 https://git.kernel.org/stable/c/faa83a7797f06cefed86731ba4baa3b4dfdc06c1 https://git.kernel.org/stable/c/c7af99cc21923a9650533c9d77265c8dd683a533 https://git.kernel.org/stable/c/989bf6fd1e1d058e73a364dce1a0c53d33373f62 https://git.kernel.org/stable/c/cfe34d86ef9765c388f145039006bb79b6c81ac6 https://git.kernel.org/stable/c/aea5e2669c2863fdd8679c40ee310b3bcaa85aec https://git.kernel.org/stable/c/d091e579b864fa790dd6a0cd537a22c383126681 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-822: Untrusted Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Fix kernel panic after setting hsuid Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL. Example: --------------------------------------------------------------------------- [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt ------------------------------------------------------------------------------------------- Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open(). Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again. Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: soluciona el pánico del kernel después de configurar hsuid Síntoma: cuando el atributo hsuid se establece por primera vez en un dispositivo IQD Layer3 mientras la interfaz de red correspondiente ya está activa, el kernel Intentará ejecutar un puntero de función napi que sea NULL. Ejemplo: ------------------------------------------------ --------------------- [ 2057.572696] operación ilegal: 0001 ilc:1 [#1] SMP [ 2057.572702] Módulos vinculados en: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat pista nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev _iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 puente stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: cargado No contaminado 4.18.0-541.el8.s390x #1 [2057.572742] Nombre de hardware: IBM 3931 A01 704 (LPAR) [2057.572744] PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [2057.572754] 00000000a3b008d8 cb923a29c779abc5 000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.5727 58] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [2057.572762] Código Krnl:#0000000000000000: 0000 ilegal &gt;00000000000 00002: 0000 ilegal 0000000000000004: 0000 ilegal 0000000000000006: 0000 ilegal 0000000000000008: 0000 ilegal 000000000000000a: 0000 ilegal 000000000000000c: 0000 ilegal 000000000000000e: 0000 ilegal [ 2057.572800] Rastreo de llamadas: [ 57.572801] ([&lt;00000000ec639700&gt;] 0xec639700) [ 2057.572803] [&lt;00000000913183e2&gt;] net_rx_action+0x2ba/0x398 [ 2057.572809 ] [&lt;0000000091515f76&gt;] __do_softirq+0x11e/0x3a0 [ 2057.572813] [&lt;0000000090ce160c&gt;] do_softirq_own_stack+0x3c/0x58 [ 2057.572817 ([&lt;0000000090d] 2cbd6&gt;] do_softirq.part.1+0x56/0x60) [ 2057.572822] [&lt;0000000090d2cc60&gt; ] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [&lt;0000000091314706&gt;] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [&lt;000003ff803dd6d6&gt;] 24e/0x300 [af_iucv] [ 2057.572830] [&lt;000003ff803dd88a&gt;] iucv_send_ctrl+0x102/0x138 [af_iucv ] [ 2057.572833] [&lt;000003ff803de72a&gt;] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [&lt;00000000912e7e90&gt;] __sys_connect+0xa0/0xd8 [ 2057.57283 9] [&lt;00000000912e9580&gt;] sys_socketcall+0x228/0x348 [ 2057.572841] [&lt;0000000091514e1a&gt; ] system_call+0x2a6/0x2c8 [ 2057.572843] Última dirección del evento de última hora: [ 2057.572844] [&lt;0000000091317e44&gt;] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] pánico - no se sincroniza: excepción fatal en la interrupción ----- -------------------------------------------------- ------------------------------------ Análisis: Hay una estructura napi por out_q: tarjeta-&gt;qdio .out_qs[i].napi Las funciones napi.poll se configuran durante qeth_open(). Desde la confirmación 1cfef80d4c2b ("s390/qeth: No llamar a dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() ya no llama a dev_close()/dev_open(). Entonces, si qeth_free_qdio_queues() borró card-&gt;qdio.out_qs[i].napi.poll mientras la interfaz de red estaba activa y la tarjeta estaba fuera de línea, no se vuelven a configurar. • https://git.kernel.org/stable/c/64e3affee2881bb22df7ce45dd1f1fd7990e382b https://git.kernel.org/stable/c/86818409f989fee29c38528ed8fb085655603356 https://git.kernel.org/stable/c/1cfef80d4c2b2c599189f36f36320b205d9447d9 https://git.kernel.org/stable/c/c33d5a5c5b2c79326190885040f1643793c67b29 https://git.kernel.org/stable/c/29d6fe395087710280f8e11d4ae79569c4cb14b7 https://git.kernel.org/stable/c/8792b557eb50b986f2496156d486d0c7c85a1524 https://git.kernel.org/stable/c/10cb803aff3b11fe0bd5f274fc1c231a43e88df6 https://git.kernel.org/stable/c/e28dd1e1bf3ebb52cdb877fb359e8978a •