CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48659 – mm/slub: fix to return errno if kmalloc() fails
https://notcve.org/view.php?id=CVE-2022-48659
In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: corrección para devolver errno si kmalloc() falla. En create_unique_id(), kmalloc(, GFP_KERNEL) puede fallar debido a falta de memoria, si falla, regrese errno correctamente en lugar de provocar pánico mediante BUG_ON(); ¡ERROR del kernel en mm/slub.c:5893! Error interno: Ups - ERROR: 0 [#1] Seguimiento de llamada SMP PREEMPT: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [ en línea] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [en línea] f2fs_init_xattr_caches+0x 78/0xb4 fs/f2fs/xattr. c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 Legacy_get_tree+0x30/0x74 fs/ fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [ en línea] __do_sys_mount fs/namespace.c:3591 [en línea] __se_sys_mount fs/namespace.c:3568 [en línea] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 • https://git.kernel.org/stable/c/81819f0fc8285a2a5a921c019e3e3d7b6169d225 https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457 https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755 https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9 https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124 https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e950 • CWE-617: Reachable Assertion •
CVSS: 8.1EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48655 – firmware: arm_scmi: Harden accesses to the reset domains
https://notcve.org/view.php?id=CVE-2022-48655
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Refuerza los accesos a los dominios de reinicio. El acceso a los descriptores de dominios de reinicio por el índice ante las solicitudes de los controladores SCMI a través de la interfaz de operaciones de reinicio de SCMI puede conducir potencialmente a violaciones fuera de los límites. si el controlador SCMI se comporta mal. Agregue una verificación de coherencia interna antes de que se acceda a dichos descriptores de dominio. • https://git.kernel.org/stable/c/95a15d80aa0de938299acfcbc6aa6f2b16f5d7e5 https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108 https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268 https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48654 – netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()
https://notcve.org/view.php?id=CVE-2022-48654
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nfnetlink_osf: corrige una posible coincidencia falsa en nf_osf_find() nf_osf_find() devuelve verdadero incorrectamente en caso de discrepancia, esto lleva a copiar el área de memoria no inicializada en nft_osf que puede usarse para filtrar el kernel obsoleto apilar datos en el espacio de usuario. • https://git.kernel.org/stable/c/22c7652cdaa8cd33ce78bacceb4e826a3f795873 https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764 https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47 https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8 • CWE-908: Use of Uninitialized Resource •
CVSS: 7.7EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48651 – ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
https://notcve.org/view.php?id=CVE-2022-48651
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvlan: corrige errores fuera de los límites causados por skb->mac_header no configurado si se usa un socket AF_PACKET para enviar paquetes a través de ipvlan y se cambia la función xmit predeterminada del socket AF_PACKET desde dev_queue_xmit() a paquete_direct_xmit() a través de setsockopt() con el nombre de opción PACKET_QDISC_BYPASS, es posible que skb->mac_header no se restablezca y permanezca en el valor inicial de 65535, esto puede desencadenar errores de losa fuera de los límites como se muestra a continuación : =================================================== ================ UG: KASAN: losa fuera de los límites en ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: cargado No contaminado 6.0.0-rc4+ #6 nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 todo Seguimiento: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+ 0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 paquete_direct_xmit+0x22/0x60 paquete_snd+0x7c9/0xc40 0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64 +0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd La causa principal es: 1. paquete_snd() solo restablece skb->mac_header cuando sock->tipo es SOCK_RAW y skb->protocolo no se especifica como en paquete_parse_headers() 2. paquete_direct_xmit() no restablece skb->mac_header como dev_queue_xmit() En este caso, skb->mac_header es 65535 cuando se llama a ipvlan_xmit_mode_l2(). Entonces, cuando ipvlan_xmit_mode_l2() obtiene el encabezado mac con eth_hdr() que usa "skb->head + skb->mac_header", se produce un acceso fuera de los límites. Este parche reemplaza eth_hdr() con skb_eth_hdr() en ipvlan_xmit_mode_l2() y restablece el encabezado de mac en multidifusión para resolver este error fuera de los límites. • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4 https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638 https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7 https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48644 – net/sched: taprio: avoid disabling offload when it was never enabled
https://notcve.org/view.php?id=CVE-2022-48644
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: evita deshabilitar la descarga cuando nunca estuvo habilitada. En una decisión de diseño de API increíblemente extraña, se llama a qdisc->destroy() incluso si qdisc->init() nunca tuvo éxito, no exclusivamente desde el commit 87b60cfacf9f ("net_sched: corregir recuperación de error en la creación de qdisc"), sino aparentemente también antes (en el caso de qdisc_create_dflt()). La qdisc taprio no reconoce completamente esto cuando intenta una descarga completa, porque comienza con q->flags = TAPRIO_FLAGS_INVALID en taprio_init(), luego reemplaza q->flags con TCA_TAPRIO_ATTR_FLAGS analizado desde netlink (en taprio_change(), cola llamada de taprio_init()). • https://git.kernel.org/stable/c/9c66d15646760eb8982242b4531c4d4fd36118fd https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76 https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323 https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92 •