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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48642 – netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()
https://notcve.org/view.php?id=CVE-2022-48642
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: corrige la pérdida de memoria de percpu en nf_tables_addchain() Me parece que la memoria de percpu para las estadísticas de la cadena comenzó a perderse desde el commit 3bc158f8d0330f0a ("netfilter: nf_tables: asigna la prioridad de la cadena base al hardware prioridad") cuando nft_chain_offload_priority() devolvió un error. • https://git.kernel.org/stable/c/3bc158f8d0330f0ac58597c023acca2234c14616 https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88 https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852 https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714 https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48641 – netfilter: ebtables: fix memory leak when blob is malformed
https://notcve.org/view.php?id=CVE-2022-48641
In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: ebtables: corrige la pérdida de memoria cuando el blob tiene un formato incorrecto La corrección del error estaba incompleta, "reemplazó" el bloqueo con una pérdida de memoria. El código antiguo tenía una asignación para "ret" incrustada en el condicional, restaurar esto. • https://git.kernel.org/stable/c/afd01382594d643e1adeb16826423b418cdf8b8b https://git.kernel.org/stable/c/358765beb836f5fc2ed26b5df4140d5d3548ac11 https://git.kernel.org/stable/c/160c4eb47db03b96c0c425358e7595ebefe8094d https://git.kernel.org/stable/c/624c30521233e110cf50ba01980a591e045036ae https://git.kernel.org/stable/c/1b2c5428f773d60c116c7b1e390432e0cfb63cd6 https://git.kernel.org/stable/c/e53cfa017bf4575d0b948a8f45313ef66d897136 https://git.kernel.org/stable/c/754e8b74281dd54a324698803483f47cf3355ae1 https://git.kernel.org/stable/c/1e98318af2f163eadaff815abcef38d27 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48639 – net: sched: fix possible refcount leak in tc_new_tfilter()
https://notcve.org/view.php?id=CVE-2022-48639
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: corrige posible fuga de recuento en tc_new_tfilter() Es necesario llamar a tfilter_put para colocar el recuento obtenido mediante tp->ops->get para evitar una posible fuga de recuento cuando se realiza la cadena. >tmplt_ops ! • https://git.kernel.org/stable/c/7d5509fa0d3ddfe252b4418513e493ac98de3317 https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596 https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7 https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88 https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5 •