CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36978 – net: sched: sch_multiq: fix possible OOB write in multiq_tune()
https://notcve.org/view.php?id=CVE-2024-36978
In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: sch_multiq: corrige posible escritura OOB en multiq_tune() q->bands se asignarán a qopt->bands para ejecutar la lógica de código posterior después de kmalloc. Por lo tanto, las antiguas q->bands no deberían usarse en kmalloc. De lo contrario, se producirá una escritura fuera de los límites. • https://git.kernel.org/stable/c/c2999f7fb05b87da4060e38150c70fa46794d82b https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3 https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882 https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129 https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36975 – KEYS: trusted: Do not use WARN when encode fails
https://notcve.org/view.php?id=CVE-2024-36975
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LLAVES: confiable: no usar WARN cuando falla la codificación Cuando falla asn1_encode_sequence(), WARN no es la solución correcta. 1. asn1_encode_sequence() no es una función interna (ubicada en lib/asn1_encode.c). 2. Se conoce la ubicación, lo que hace que el seguimiento de la pila sea inútil. 3. • https://git.kernel.org/stable/c/f2219745250f388edacabe6cca73654131c67d0a https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972 https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087 https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487 https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b •
CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36974 – net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
https://notcve.org/view.php?id=CVE-2024-36974
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: validar siempre TCA_TAPRIO_ATTR_PRIOMAP Si se ha proporcionado un atributo TCA_TAPRIO_ATTR_PRIOMAP, taprio_parse_mqprio_opt() debe validarlo, o el espacio de usuario puede inyectar datos arbitrarios al kernel, la segunda vez taprio_change () se llama. La primera llamada (con atributos válidos) establece dev->num_tc en un valor distinto de cero. La segunda llamada (con atributos mqprio arbitrarios) regresa temprano desde taprio_parse_mqprio_opt() y pueden suceder cosas malas. • https://git.kernel.org/stable/c/a3d43c0d56f1b94e74963a2fbadfb70126d92213 https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923 https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404 https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2 https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519 • CWE-787: Out-of-bounds Write •
CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36972 – af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock.
https://notcve.org/view.php?id=CVE-2024-36972
In the Linux kernel, the following vulnerability has been resolved: af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock. Billy Jheng Bing-Jhong reported a race between __unix_gc() and queue_oob(). __unix_gc() tries to garbage-collect close()d inflight sockets, and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC will drop the reference and set NULL to it locklessly. However, the peer socket still can send MSG_OOB message and queue_oob() can update unix_sk(sk)->oob_skb concurrently, leading NULL pointer dereference. [0] To fix the issue, let's update unix_sk(sk)->oob_skb under the sk_receive_queue's lock and take it everywhere we touch oob_skb. Note that we defer kfree_skb() in manage_oob() to silence lockdep false-positive (See [1]). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events delayed_fput RIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847) Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002 RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9 RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00 RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00 R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80 FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> unix_release_sock (net/unix/af_unix.c:654) unix_release (net/unix/af_unix.c:1050) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:423) delayed_fput (fs/file_table.c:444 (discriminator 3)) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) </TASK> Modules linked in: CR2: 0000000000000008 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: actualice unix_sk(sk)->oob_skb bajo el bloqueo sk_receive_queue. Billy Jheng Bing-Jhong informó de una ejecución entre __unix_gc() y queue_oob(). __unix_gc() intenta recolectar basura de sockets en vuelo close()d, y luego, si el socket tiene MSG_OOB en unix_sk(sk)->oob_skb, GC eliminará la referencia y establecerá NULL sin bloqueo. • https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668 https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276 https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140 https://git.kernel.org/stable/c/518a994aa0b87d96f1bc6678a7035df5d1fcd7a1 https://git.kernel.org/stable/c/4bf6964451c3cb411fbaa1ae8b214b3d97a59bf1 https://git.kernel.org/stable/c/d59ae9314b97e01c76a4171472441e557 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36971 – Android Kernel Remote Code Execution Vulnerability
https://notcve.org/view.php?id=CVE-2024-36971
In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: fix __dst_negative_advice() race __dst_negative_advice() no aplica las reglas adecuadas de RCU cuando se debe borrar sk->dst_cache, lo que genera una posible UAF. Las reglas de RCU son que primero debemos borrar sk->sk_dst_cache y luego llamar a dst_release(old_dst). Tenga en cuenta que sk_dst_reset(sk) implementa este protocolo correctamente, mientras que __dst_negative_advice() utiliza el orden incorrecto. Dado que ip6_negative_advice() tiene una lógica especial contra RTF_CACHE, esto significa que cada uno de los tres ->negative_advice() métodos existentes debe realizar sk_dst_reset() ellos mismos. • https://git.kernel.org/stable/c/a87cb3e48ee86d29868d3f59cfb9ce1a8fa63314 https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13 https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72 https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6 https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4 https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508 https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a • CWE-416: Use After Free •