CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35847 – irqchip/gic-v3-its: Prevent double free on error
https://notcve.org/view.php?id=CVE-2024-35847
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3-its: Evitar el double free en caso de error. La ruta de manejo de errores en its_vpe_irq_domain_alloc() provoca un double free cuando its_vpe_init() falla después de asignar exitosamente al menos una interrupción. Esto sucede porque its_vpe_irq_domain_free() libera las interrupciones junto con el mapa de bits del área y la vprop_page y its_vpe_irq_domain_alloc() posteriormente libera nuevamente el mapa de bits del área y la vprop_page. Solucione este problema invocando incondicionalmente its_vpe_irq_domain_free() que maneja todos los casos correctamente y eliminando el mapa de bits/vprop_page que se libera de its_vpe_irq_domain_alloc(). • https://git.kernel.org/stable/c/7d75bbb4bc1ad90386776459d37e4ddfe605671e https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662 https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52 https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438 https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9 https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792 https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fe •
CVSS: 6.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35843 – iommu/vt-d: Use device rbtree in iopf reporting path
https://notcve.org/view.php?id=CVE-2024-35843
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. • https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15 https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a https://access.redhat.com/security/cve/CVE-2024-35843 https://bugzilla.redhat.com/show_bug.cgi?id=2281276 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35839 – netfilter: bridge: replace physindev with physinif in nf_bridge_info
https://notcve.org/view.php?id=CVE-2024-35839
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb. • https://git.kernel.org/stable/c/c4e70a87d975d1f561a00abfe2d3cefa2a486c95 https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547 https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86 https://access.redhat.com/security/cve/CVE-2024-35839 https://bugzilla.redhat.com/show_bug.cgi?id=2281284 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52698 – calipso: fix memory leak in netlbl_calipso_add_pass()
https://notcve.org/view.php?id=CVE-2023-52698
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 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: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: calipso: corrige la pérdida de memoria en netlbl_calipso_add_pass() Si la compatibilidad con IPv6 está deshabilitada en el arranque (ipv6.disable=1), no se llama a la función calipso_init() -> netlbl_calipso_ops_register() y la función netlbl_calipso_ops_get() siempre devuelve NULL. En este caso, la función netlbl_calipso_add_pass() asigna memoria para la variable doi_def pero no la libera con calipso_doi_free(). ERROR: pérdida de memoria, objeto sin referencia 0xffff888011d68180 (tamaño 64): comunicación "syz-executor.1", pid 10746, jiffies 4295410986 (edad 17,928 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 02 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 ................. ... seguimiento: [<...>] kmalloc include/linux/slab.h:552 [en línea] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [en línea] [<... • https://git.kernel.org/stable/c/cb72d38211eacda2dd90b09540542b6582da614e https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53 https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01 https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149 https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031 https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52693 – ACPI: video: check for error while searching for backlight device parent
https://notcve.org/view.php?id=CVE-2023-52693
In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: vídeo: comprueba si hay errores al buscar el dispositivo de retroiluminación principal. Si la llamada acpi_get_parent() en acpi_video_dev_register_backlight() fallo, por ejemplo, porque acpi_ut_acquire_mutex() fallo dentro de acpi_get_parent), esto puede provocar que se pase el identificador acpi_parent incorrecto (no inicializado) a acpi_get_pci_dev() para detectar el dispositivo pci principal. Verifique el resultado de acpi_get_parent() y configure el dispositivo principal solo en caso de éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/9661e92c10a9775243c1ecb73373528ed8725a10 https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8 https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3 https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95 https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852 •