CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36931 – s390/cio: Ensure the copied buf is NUL terminated
https://notcve.org/view.php?id=CVE-2024-36931
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: 0CVE-2024-36930 – spi: fix null pointer dereference within spi_sync
https://notcve.org/view.php?id=CVE-2024-36930
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->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: 0CVE-2024-36929 – net: core: reject skb_copy(_expand) for fraglist GSO skbs
https://notcve.org/view.php?id=CVE-2024-36929
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: 0CVE-2024-36928 – s390/qeth: Fix kernel panic after setting hsuid
https://notcve.org/view.php?id=CVE-2024-36928
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 >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] ([<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 ([<0000000090d] 2cbd6>] 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>] 24e/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.57283 9] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a> ] system_call+0x2a6/0x2c8 [ 2057.572843] Última dirección del evento de última hora: [ 2057.572844] [<0000000091317e44>] __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->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->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 •
CVSS: 5.5EPSS: 0%CPEs: 11EXPL: 0CVE-2024-36927 – ipv4: Fix uninit-value access in __ip_make_skb()
https://notcve.org/view.php?id=CVE-2024-36927
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix uninit-value access in __ip_make_skb() KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL while __ip_make_skb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN. Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL on the socket. Also, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. • https://git.kernel.org/stable/c/99e5acae193e369b71217efe6f1dad42f3f18815 https://git.kernel.org/stable/c/dc4e3bb0710178c8d03fc43064e0a71fe7440cdd https://git.kernel.org/stable/c/022ea4374c319690c804706bda9dc42946d1556d https://git.kernel.org/stable/c/27c468ec1af113f6ae94fb5378f65e6038bd16e7 https://git.kernel.org/stable/c/566785731c6dd41ef815196ddc36d1ae30a63763 https://git.kernel.org/stable/c/a54ec573d9b81b05d368f8e6edc1b3e49f688658 https://git.kernel.org/stable/c/fc60067260c20da8cddcf968bec47416f3e2cde2 https://git.kernel.org/stable/c/32a5a13d556e4f804e5a447a08c70b172 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •