CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48645 – net: enetc: deny offload of tc-based TSN features on VF interfaces
https://notcve.org/view.php?id=CVE-2022-48645
In the Linux kernel, the following vulnerability has been resolved: net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root 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 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: denegar la descarga de funciones TSN basadas en tc en interfaces VF Las funciones TSN en ENETC (taprio, cbs, gate, policial) se configuran mediante una combinación de comandos BD ring mensajes y registros de puertos: enetc_port_rd(), enetc_port_wr(). Los registros de puerto son una región del mapa de memoria ENETC a la que solo se puede acceder desde la función física PCIe. • https://git.kernel.org/stable/c/34c6adf1977b611fca3b824ad12a2a415e1e420e https://git.kernel.org/stable/c/510e703e4ed0e011db860bc21228aff48fc9eea7 https://git.kernel.org/stable/c/23022b74b1a23bed044f6bc96cf92f6ca5f3e75f https://git.kernel.org/stable/c/5641c751fe2f92d3d9e8a8e03c1263ac8caa0b42 •
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 •