CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26632 – block: Fix iterating over an empty bio with bio_for_each_folio_all
https://notcve.org/view.php?id=CVE-2024-26632
In the Linux kernel, the following vulnerability has been resolved: block: Fix iterating over an empty bio with bio_for_each_folio_all If the bio contains no data, bio_first_folio() calls page_folio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bio_next_folio() to bio_first_folio(). [axboe: add unlikely() to error case] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige la iteración sobre una biografía vacía con bio_for_each_folio_all Si la biografía no contiene datos, bio_first_folio() llama a page_folio() en un puntero NULL y ¡vaya! Mueve la prueba de que hemos llegado al final de la biografía de bio_next_folio() a bio_first_folio(). [axboe: agregue improbable() al caso de error] • https://git.kernel.org/stable/c/640d1930bef4f87ec8d8d2b05f0f6edc1dfcf662 https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659 https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7 •
CVSS: 2.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26631 – ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
https://notcve.org/view.php?id=CVE-2024-26631
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: corrige data-race en ipv6_mc_down / mld_ifc_work idev->mc_ifc_count se puede sobrescribir sin el bloqueo adecuado. Originalmente encontrado por syzbot [1], solucione este problema encapsulando las llamadas a mld_ifc_stop_work() (y mld_gq_stop_work() por si acaso) con mutex_lock() y mutex_unlock() en consecuencia, ya que estas funciones solo deben llamarse con mc_lock según sus declaraciones. [1] ERROR: KCSAN: carrera de datos en ipv6_mc_down / mld_ifc_work escribir en 0xffff88813a80c832 de 1 bytes por tarea 3771 en la CPU 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [en línea] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast .c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [en línea] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flag s+0x205/ 0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [en línea] __rtnl_newlink net/core/rtnetlink.c :3717 [en línea] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0 x1c /0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [en línea] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c :1910 ... escriba en 0xffff88813a80c832 de 1 bytes por tarea 22 en la CPU 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 Process_one_work kernel/workqueue.c:2627 [en línea] Process_scheduled_works+0x5b8/0xa30 kernel/ workqueue.c:2700 trabajador_thread+0x525/0x730 kernel/workqueue.c:2781 ... • https://git.kernel.org/stable/c/2d9a93b4902be6a5504b5941dd15e9cd776aadca https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663 https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900 https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855 https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155 https://access.redhat.com/security/cve/CVE-2024-26631 https://bugzilla.redhat.com/show_bug.cgi?id=2270133 • CWE-414: Missing Lock Check •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52612 – crypto: scomp - fix req->dst buffer overflow
https://notcve.org/view.php?id=CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: scomp - corrige el desbordamiento del búfer req->dst. El tamaño del búfer req->dst debe verificarse antes de copiar desde scomp_scratch->dst para evitar el problema de desbordamiento del búfer req->dst. . • https://git.kernel.org/stable/c/1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76 https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625 https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5 https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759 https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf •
CVSS: 6.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52610 – net/sched: act_ct: fix skb leak and crash on ooo frags
https://notcve.org/view.php?id=CVE-2023-52610
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix skb leak and crash on ooo frags act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in: inet_frag_reasm_prepare skb_morph which is not straightforward. However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time. Fix the issue by removing skb_get() before defragmentation. act_ct returns TC_ACT_CONSUMED when defrag failed or in progress. [0]: [ 843.804823] ------------[ cut here ]------------ [ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? • https://git.kernel.org/stable/c/b57dc7c13ea90e09ae15f821d2583fa0231b4935 https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4 https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4 https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97 https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441 https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6 https://access.redhat.com/security/cve/CVE-2023-52610 https://bugzilla.redhat.com/show_bug.cgi?id=2270080 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
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 •