CVSS: 3.3EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26911 – drm/buddy: Fix alloc_range() error handling code
https://notcve.org/view.php?id=CVE-2024-26911
In the Linux kernel, the following vulnerability has been resolved: drm/buddy: Fix alloc_range() error handling code Few users have observed display corruption when they boot the machine to KDE Plasma or playing games. We have root caused the problem that whenever alloc_range() couldn't find the required memory blocks the function was returning SUCCESS in some of the corner cases. The right approach would be if the total allocated size is less than the required size, the function should return -ENOSPC. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/buddy: corrige el código de manejo de errores alloc_range() Pocos usuarios han observado daños en la pantalla cuando inician la máquina en KDE Plasma o juegan juegos. Hemos causado el problema de que cada vez que alloc_range() no podía encontrar los bloques de memoria requeridos, la función devolvía ÉXITO en algunos de los casos de esquina. El enfoque correcto sería que si el tamaño total asignado es menor que el tamaño requerido, la función debería devolver -ENOSPC. • https://git.kernel.org/stable/c/0a1844bf0b532d84324453374ad6845f64066c28 https://git.kernel.org/stable/c/4b59c3fada06e5e8010ef7700689c71986e667a2 https://git.kernel.org/stable/c/8746c6c9dfa31d269c65dd52ab42fde0720b7d91 • CWE-755: Improper Handling of Exceptional Conditions •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26910 – netfilter: ipset: fix performance regression in swap operation
https://notcve.org/view.php?id=CVE-2024-26910
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: ipset: corrige la regresión de rendimiento en la operación de intercambio El parche "netfilter: ipset: corrige la condición de ejecución entre swap/destroy y add/del/test del lado del kernel", commit 28628fa9 corrige un condición de ejecución. Pero elsync_rcu() agregado a la función swap la ralentiza innecesariamente: se puede mover con seguridad para destruir y usar call_rcu() en su lugar. Eric Dumazet señaló que simplemente llamar a las funciones de destrucción como devolución de llamada de rcu no funciona: los conjuntos con tiempo de espera usan recolectores de basura que necesitan cancelarse en la destrucción y que pueden esperar. • https://git.kernel.org/stable/c/427deb5ba5661c4ae1cfb35955d2e01bd5f3090a https://git.kernel.org/stable/c/e7152a138a5ac77439ff4e7a7533448a7d4c260d https://git.kernel.org/stable/c/8bb930c3a1eacec1b14817f565ff81667c7c5dfa https://git.kernel.org/stable/c/875ee3a09e27b7adb7006ca6d16faf7f33415aa5 https://git.kernel.org/stable/c/23c31036f862582f98386120aee55c9ae23d7899 https://git.kernel.org/stable/c/28628fa952fefc7f2072ce6e8016968cc452b1ba https://git.kernel.org/stable/c/a12606e5ad0cee8f4ba3ec68561c4d6275d2df57 https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 4.7EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52645 – pmdomain: mediatek: fix race conditions with genpd
https://notcve.org/view.php?id=CVE-2023-52645
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: mediatek: corrige las condiciones de ejecución con genpd, si los dominios de energía se registran primero con genpd y *después de eso* el controlador intenta encenderlos en la secuencia de sonda, entonces es Es posible que se produzca una condición de ejecución si genpd intenta encenderlos al mismo tiempo. Lo mismo es válido para apagarlos antes de cancelar su registro en genpd. Intente arreglar las condiciones de ejecución eliminando primero los dominios de genpd y *después* apagando los dominios. También primero encienda los dominios y *después* regístrelos en genpd. • https://git.kernel.org/stable/c/59b644b01cf48d6042f3c5983d464921a4920845 https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438 https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25 https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26909 – soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
https://notcve.org/view.php?id=CVE-2024-26909
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free A recent DRM series purporting to simplify support for "transparent bridges" and handling of probe deferrals ironically exposed a use-after-free issue on pmic_glink_altmode probe deferral. This has manifested itself as the display subsystem occasionally failing to initialise and NULL-pointer dereferences during boot of machines like the Lenovo ThinkPad X13s. Specifically, the dp-hpd bridge is currently registered before all resources have been acquired which means that it can also be deregistered on probe deferrals. In the meantime there is a race window where the new aux bridge driver (or PHY driver previously) may have looked up the dp-hpd bridge and stored a (non-reference-counted) pointer to the bridge which is about to be deallocated. When the display controller is later initialised, this triggers a use-after-free when attaching the bridges: dp -> aux -> dp-hpd (freed) which may, for example, result in the freed bridge failing to attach: [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 or a NULL-pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... Call trace: drm_bridge_attach+0x70/0x1a8 [drm] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] drm_bridge_attach+0x80/0x1a8 [drm] dp_bridge_init+0xa8/0x15c [msm] msm_dp_modeset_init+0x28/0xc4 [msm] The DRM bridge implementation is clearly fragile and implicitly built on the assumption that bridges may never go away. In this case, the fix is to move the bridge registration in the pmic_glink_altmode driver to after all resources have been looked up. Incidentally, with the new dp-hpd bridge implementation, which registers child devices, this is also a requirement due to a long-standing issue in driver core that can otherwise lead to a probe deferral loop (see commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")). [DB: slightly fixed commit message by adding the word 'commit'] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Una serie reciente de DRM que pretende simplificar el soporte para "puentes transparentes" y el manejo de aplazamientos de sonda expuso irónicamente un uso posterior -Problema gratuito en el aplazamiento de la sonda pmic_glink_altmode. Esto se ha manifestado como que el subsistema de visualización ocasionalmente falla al inicializarse y se eliminan las referencias del puntero NULL durante el arranque de máquinas como la Lenovo ThinkPad X13s. Específicamente, el puente dp-hpd actualmente está registrado antes de que se hayan adquirido todos los recursos, lo que significa que también se puede cancelar su registro en caso de aplazamientos de sonda. Mientras tanto, hay una ventana de carrera donde el nuevo controlador del puente auxiliar (o el controlador PHY anteriormente) puede haber buscado el puente dp-hpd y almacenado un puntero (sin recuento de referencias) al puente que está a punto de ser desasignado. • https://git.kernel.org/stable/c/080b4e24852b1d5b66929f69344e6c3eeb963941 https://git.kernel.org/stable/c/2bbd65c6ca567ed8dbbfc4fb945f57ce64bef342 https://git.kernel.org/stable/c/ef45aa2841e15b649e5417fe3d4de395fe462781 https://git.kernel.org/stable/c/b979f2d50a099f3402418d7ff5f26c3952fb08bb • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26907 – RDMA/mlx5: Fix fortify source warning while accessing Eth segment
https://notcve.org/view.php?id=CVE-2024-26907
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? • https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21 https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2024 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-416: Use After Free •