CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26833 – drm/amd/display: Fix memory leak in dm_sw_fini()
https://notcve.org/view.php?id=CVE-2024-26833
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la pérdida de memoria en dm_sw_fini() Después de destruir dmub_srv, la memoria asociada a él no se libera, lo que provoca una pérdida de memoria: objeto sin referencia 0xffff896302b45800 (tamaño 1024) : comm "(udev-worker)", pid 222, sjiffies 4294894636 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........... ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 6265fd77): [] kmalloc_trace+ 0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] 1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15 /0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [ ] realmente_probe+0xe2/0x480 [< ffffffff99805c98>] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] v+0x70/0xc0 [] bus_add_driver+0x112/0x210 [< ffffffff99807245>] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300 Solucione este problema liberando dmub_srv después de destruirlo. • https://git.kernel.org/stable/c/743b9786b14ae0d7d13b3782dccad158e577e9bb https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857 https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30 https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2 https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26832 – mm: zswap: fix missing folio cleanup in writeback race path
https://notcve.org/view.php?id=CVE-2024-26832
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: zswap: corrige la limpieza de folio faltante en la ruta de carrera de escritura diferida En zswap_writeback_entry(), después de obtener un folio de __read_swap_cache_async(), tomamos el bloqueo del árbol nuevamente para verificar que el intercambio la entrada no fue invalidada y reciclada. Si así fuera, eliminamos la publicación que acabamos de agregar al caché de intercambio y salimos. • https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a https://git.kernel.org/stable/c/04fc7816089c5a32c29a04ec94b998e219dfb946 https://git.kernel.org/stable/c/ba700ea13bf0105a4773c654f7d3bef8adb64ab2 https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644 https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe https://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26829 – media: ir_toy: fix a memleak in irtoy_tx
https://notcve.org/view.php?id=CVE-2024-26829
In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ir_toy: corrige una fuga de mem en irtoy_tx Cuando falla irtoy_command, se debe liberar buf ya que está asignado por irtoy_tx, o hay una fuga de mem. • https://git.kernel.org/stable/c/4114978dcd24e72415276bba60ff4ff355970bbc https://git.kernel.org/stable/c/a4ac45aff8d38c64104aec21c6529747d94ae75a https://git.kernel.org/stable/c/486a4176bc783df798bce2903824801af8d2c3ae https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff https://git.kernel.org/stable/c/be76ad74a43f90f340f9f479e6b04f02125f6aef https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621 https://git.kernel.org/stable/c/dc9ceb90c4b42c6e5c6757df1d6257110 •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26830 – i40e: Do not allow untrusted VF to remove administratively set MAC
https://notcve.org/view.php?id=CVE-2024-26830
In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: No permitir que VF que no es de confianza elimine la MAC configurada administrativamente. Actualmente, cuando PF configura administrativamente la dirección MAC de VF y el VF se desactiva (VF intenta eliminar todas las MAC), entonces la MAC se eliminado de los filtros MAC y el MAC VF primario se pone a cero. No permita que VF que no es de confianza elimine la MAC principal cuando PF la configuró administrativamente. Reproductor: 1) Crear VF 2) Configurar la interfaz VF 3) Configurar administrativamente la MAC del VF 4) Colocar la interfaz VF [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@ host ~]# enlace ip establecido enp2s0f0v0 up [root@host ~]# enlace ip establecido enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# enlace ip show enp2s0f0 23: enp2s0f0: < BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq estado Modo UP DEFAULT grupo predeterminado qlen 1000 enlace/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 enlace/ ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada [root@host ~]# enlace IP configurado enp2s0f0v0 inactivo [raíz @host ~]# ip link show enp2s0f0 23: enp2s0f0: mtu 1500 qdisc mq state Modo UP DEFAULT grupo predeterminado qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff :ff:ff:ff:ff:ff vf 0 enlace/éter 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada A flaw was found in Intel network adapters in the Linux kernel, where untrusted virtualized network interfaces can remove MAC addresses set by the system. This flaw allows an attacker with sufficient privileges to cause a denial of service. • https://git.kernel.org/stable/c/700bbf6c1f9e4ab055528d5ab4ac5815fe4a6c1b https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893 https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404 https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc https://access.redhat.com/security/cve/CVE-2024-26830 https://bugzilla.redhat.com/show_bug.cgi?id=2275596 • CWE-20: Improper Input Validation •
CVSS: 6.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26828 – cifs: fix underflow in parse_server_interfaces()
https://notcve.org/view.php?id=CVE-2024-26828
In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige el desbordamiento insuficiente en parse_server_interfaces() En este bucle, recorremos el búfer y después de cada elemento comprobamos si size_left es mayor que el tamaño mínimo que necesitamos. Sin embargo, el problema es que "bytes_left" es del tipo ssize_t mientras que sizeof() es del tipo size_t. • https://git.kernel.org/stable/c/fe856be475f7cf5ffcde57341d175ce9fd09434b https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512 https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308 https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301 https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204 https://access.redhat.com/security/cve/CVE-2024-26828 https://bugzilla.redhat.com/show_bug.cgi?id=2275600 • CWE-191: Integer Underflow (Wrap or Wraparound) •