CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52617 – PCI: switchtec: Fix stdev_release() crash after surprise hot remove
https://notcve.org/view.php?id=CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). • https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355 https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8 https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3 https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693 https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26636 – llc: make llc_ui_sendmsg() more robust against bonding changes
https://notcve.org/view.php?id=CVE-2024-26636
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: hacer que llc_ui_sendmsg() sea más robusto contra cambios de vinculación syzbot pudo engañar a llc_ui_sendmsg(), asignando un skb sin espacio libre, pero posteriormente intentó enviar 14 bytes de encabezado Ethernet [ 1] Como otros, llc_ui_sendmsg() libera el bloqueo del socket antes de llamar a sock_alloc_send_skb(). Luego lo adquiere nuevamente, pero no rehace todas las comprobaciones de cordura que se realizaron. Esta solución: - Utiliza LL_RESERVED_SPACE() para reservar espacio. - Verifique todas las condiciones nuevamente después de mantener nuevamente el bloqueo del casquillo. - No tenga en cuenta el encabezado Ethernet para la limitación de mtu. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 ERROR del kernel en net/core/skbuff.c:193. Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6875 Comm: syz-executor.0 No contaminado 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Nombre del hardware : Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:189 [en línea] pc: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr: skb_panic net/core/skbuff.c:189 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp: ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c 9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x1 7: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: e28a51f1087e8400 x8: e28a 51f1087e8400 x7: ffff80008028f8d0 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: ffff800082b78714 x2: 00000000000000 001 x1: 0000000100000000 x0: 0000000000000089 Rastreo de llamadas: skb_panic net/core /skbuff.c:189 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c: 83 dev_hard_header include/linux/netdevice.h:3188 [en línea] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_ acciones net/llc/llc_sap.c :153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ ui_sendmsg+0x7bc/ 0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs /splice.c:881 do_splice_from fs/splice.c:933 [en línea] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice. c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [en línea] __se_sys_sendfile64 fs/read_write.c:1308 [en línea] __arm64_sys_sendfile64+0x160/0x3b4 fs /read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/ 0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+ 0x190/0x194 arch/arm64/kernel/entry.S:595 Código: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249 https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4 https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565f •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52615 – hwrng: core - Fix page fault dead lock on mmap-ed hwrng
https://notcve.org/view.php?id=CVE-2023-52615
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwrng: core: soluciona el bloqueo de falla de página en mmap-ed hwrng Hay un bloqueo en la ruta de lectura del dispositivo hwrng. Esto se activa cuando el usuario lee desde /dev/hwrng en la memoria y también realiza mmap-ed desde /dev/hwrng. • https://git.kernel.org/stable/c/9996508b3353063f2d6c48c1a28a84543d72d70b https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990 https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48 https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0 https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52609 – binder: fix race between mmput() and do_exit()
https://notcve.org/view.php?id=CVE-2023-52609
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. • https://git.kernel.org/stable/c/457b9a6f09f011ebcb9b52cc203a6331a6fc2de7 https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608 https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097 https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918 https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9 https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3 https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47119 – ext4: fix memory leak in ext4_fill_super
https://notcve.org/view.php?id=CVE-2021-47119
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_fill_super Buffer head references must be released before calling kill_bdev(); otherwise the buffer head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using kill_bdev(). And then super block will be reread again but using correct blocksize this time. sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start <ext4_on_lvm>.mount, and systemctl stop <ext4_on_lvm>.mount ... since systemd creates a cgroup for each slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed, and memory consumption is much more easily noticed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la pérdida de memoria en ext4_fill_super Las referencias del encabezado del búfer deben liberarse antes de llamar a kill_bdev(); de lo contrario, kill_bdev no liberará el encabezado del búfer (y su página a la que hace referencia b_data) y, posteriormente, se filtrará ese bh. Si los tamaños de los bloques difieren, sb_set_blocksize() eliminará los búferes actuales y el caché de la página usando kill_bdev(). Y luego el superbloque se volverá a leer, pero esta vez utilizando el tamaño de bloque correcto. sb_set_blocksize() no liberó completamente la página del superbloque y el encabezado del búfer y, al estar ocupados, no se liberaron y en su lugar se filtraron. • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/01d349a481f0591230300a9171330136f9159bcd https://git.kernel.org/stable/c/1385b23396d511d5233b8b921ac3058b3f86a5e1 https://git.kernel.org/stable/c/afd09b617db3786b6ef3dc43e28fe728cfea84df •