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: 3EXPL: 0CVE-2022-48640 – bonding: fix NULL deref in bond_rr_gen_slave_id
https://notcve.org/view.php?id=CVE-2022-48640
In the Linux kernel, the following vulnerability has been resolved: bonding: fix NULL deref in bond_rr_gen_slave_id Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c ---truncated--- En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bonding: corrige la deref NULL en bond_rr_gen_slave_id Se corrige una desreferencia NULL del miembro struct bonding.rr_tx_counter porque si un enlace se crea inicialmente con un modo inicial != cero (Round Robin) la memoria requerido para el contador nunca se crea y cuando se cambia el modo nunca se intenta verificar que la memoria esté asignada al cambiar de modo. Esto provoca los siguientes errores en una máquina aarch64: [334.686773] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff2c91ac905000 [334.694703] Información de cancelación de memoria: [334.697486] ESR = 0x0000000096000004 [334.701234] EC = 0x25: DABT (EL actual), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: error de traducción de nivel 0 [ 334.717586] Información de cancelación de datos: [ 334.720454] ISV = 0, ISS = 0x00000004 [334.724288] CM = 0, WnR = 0 [334.727244] tabla de intercambio: páginas 4k, VA de 48 bits, pgdp=000008044d662000 [334.733944] [ffff2c91ac905000] 0000000000000, p4d=00000000000000000 [334.740734] Error interno: Ups: 96000004 [#1] SMP [334.745602] Módulos vinculados en: unión tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [334.772217] CPU: 7 PID: 2214 Comm: ping No contaminado 6.0.0-rc4-00133-g64ae13ed4784 #4 [334.779950] Nombre de hardware: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01 /2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [unión] [ 334.801691] lr : _slave_get+0x38/0xdc [ vinculación] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 00000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x 20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] 14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 3 34.861153] x8: ffff07ff9f6e5a28 x7: 0000000000000000 x6: 000000007c2b3742 [334.868279] x5: ffff2c91ac905000 x4: ffff2c91ac905000 x3: ffff07ff9f554400 [334.875406] x2: 1ac905000 x1: 0000000000000001 x0: ffff07ff981029c0 [334.882532] Rastreo de llamadas: [334.884967] bond_rr_gen_slave_id+0x40/0x124 [vinculación] [334.890109] _obtener+ 0x38/0xdc [vínculo] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [vínculo] [ 334.901001] bond_start_xmit+0x54/0xb0 [vínculo] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334 .909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c /0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] 0x470 [334.931453] neigh_resolve_output+0x70/0x90 [334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] 0 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325 ] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c ncado--- • https://git.kernel.org/stable/c/848ca9182a7d25bb54955c3aab9a3a2742bf9678 https://git.kernel.org/stable/c/ec3a6f4ffe556a28f6f5028bf7c4412557e7051b https://git.kernel.org/stable/c/2c8e8ab53acfc78da0b4a65f30cb5d306e7d78f7 https://git.kernel.org/stable/c/0e400d602f46360752e4b32ce842dba3808e15e6 •
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 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48638 – cgroup: cgroup_get_from_id() must check the looked-up kn is a directory
https://notcve.org/view.php?id=CVE-2022-48638
In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cgroup: cgroup_get_from_id() debe verificar que el kn buscado sea un directorio. cgroup tiene que ser un directorio kernfs; de lo contrario, se produce un pánico en el kernel, especialmente la identificación de cgroup se proporciona desde el espacio de usuario. A flaw was found in the Linux kernel in which certain cgroup configurations could cause a kernel panic, resulting in a Denial of Service. • https://git.kernel.org/stable/c/6b658c4863c15936872a93c9ee879043bf6393c9 https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37 https://access.redhat.com/security/cve/CVE-2022-48638 https://bugzilla.redhat.com/show_bug.cgi?id=2277829 • CWE-588: Attempt to Access Child of a Non-structure Pointer •