Skip to content
Fencer Vulns
medium 5.5

CVE-2022-50396 json

net: sched: fix memory leak in tcindex_set_parms

published 2025-09-18 13 mo ago modified 2026-06-17 4 mo ago also EUVD-2025-29973

cvss
5.5
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 6%
public exploits
0
none known

Summary

In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix memory leak in tcindex_set_parms

Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline] [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ====================================

Kernel uses tcindex_change() to change an existing filter properties.

Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure, which triggers the above memory leak.

To be more specific, there are only two source for the `old_r`, according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from `p->h`.

* If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated. So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure

* If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel ignores using tcindex_filter_result_init() to clear the old filter result.

So only when `old_r` is retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result, which triggers the above memory leak.

Considering that there already exists a tc_filter_wq workqueue to destroy the old tcindex_d ---truncated---

Patch / fix

  • Linux Linux 4.14.308, 4.19.276, 5.4.229, 5.4.235, 5.10.163, 5.10.173, 5.15.87, 5.15.100, 6.0.19, 6.1.5, 6.1.18, 6.2, 6.2.5
  • linux Debian 14, Debian 13, Debian 12 6.1.7-1

debian advisories DEBIAN-CVE-2022-50396

  • linux Ubuntu 20.04 LTS 5.4.0-144.161
  • linux Ubuntu 22.04 LTS 5.15.0-69.76
  • linux-aws Ubuntu 20.04 LTS 5.4.0-1097.105
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1033.37
  • linux-gcp Ubuntu 20.04 LTS 5.4.0-1101.110
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1031.38
  • linux-gke Ubuntu 22.04 LTS 5.15.0-1030.35
  • linux-ibm Ubuntu 20.04 LTS 5.4.0-1045.50

ubuntu advisories UBUNTU-CVE-2022-50396

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel RHEL 8 4.18.0-513.5.1.el8_9
  • perf RHEL 8 4.18.0-513.5.1.el8_9
  • bpftool RHEL 8 4.18.0-513.5.1.el8_9
  • kernel-core RHEL 8 4.18.0-513.5.1.el8_9
  • kernel-tools RHEL 8 4.18.0-513.5.1.el8_9
  • python3-perf RHEL 8 4.18.0-513.5.1.el8_9
  • kernel-modules RHEL 8 4.18.0-513.5.1.el8_9
  • kernel-zfcpdump RHEL 8 4.18.0-513.5.1.el8_9

red hat advisories RHSA-2023:7077RHSA-2023:2458RHSA-2023:4130

  • kernel-rt SLE Micro 5.5 5.14.21-150500.13.109.1
  • kernel-source-rt SLE Micro 5.5 5.14.21-150500.13.109.1
  • kernel-64kb SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS, SLE High Performance Computing 15 SP5-ESPOS 5.14.21-150500.55.124.1
  • kernel-syms SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS +1 more 5.14.21-150500.55.124.1
  • kernel-source SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +2 more 5.14.21-150500.55.124.1
  • kernel-default SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +3 more 5.14.21-150500.55.124.1
  • kernel-obs-build SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS +1 more 5.14.21-150500.55.124.1
  • kernel-default-base SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +2 more 5.14.21-150500.55.124.1.150500.6.59.1

suse advisories SUSE-SU-2025:3761-1SUSE-SU-2025:03615-1SUSE-SU-2025:03614-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2022-50396 updated cvss 5.5

kernel: net: sched: fix memory leak in tcindex_set_parms

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 kernel-rt, kernel-rt-kvm, kernel-rt-core, kernel-rt-modules, kernel-rt-debug-kvm, kernel-rt-debug-core, +6 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-kvm, kernel-rt-core, kernel-rt-modules, kernel-rt-debug-kvm, kernel-rt-debug-core, +12 more
    affected: no fix available “Fix deferred”
  • Red Hat CodeReady Linux Builder (v. 8) kernel-debuginfo-common-x86_64 4.18.0-513.5.1.el8_9, kernel-debuginfo-common-aarch64 4.18.0-513.5.1.el8_9, kernel-debuginfo-common-ppc64le 4.18.0-513.5.1.el8_9
    fixed: vendor fix RHSA-2023:7077
  • Red Hat CodeReady Linux Builder EUS (v.8.6) kernel-debuginfo-common-x86_64 4.18.0-372.64.1.el8_6, kernel-debuginfo-common-aarch64 4.18.0-372.64.1.el8_6, kernel-debuginfo-common-ppc64le 4.18.0-372.64.1.el8_6
    fixed: vendor fix RHSA-2023:4130
  • Red Hat Enterprise Linux AppStream (v. 9) perf 5.14.0-284.11.1.el9_2, rtla 5.14.0-284.11.1.el9_2, kernel-devel-matched 5.14.0-284.11.1.el9_2, kernel-64k-devel-matched 5.14.0-284.11.1.el9_2, kernel-debug-devel-matched 5.14.0-284.11.1.el9_2, kernel-debuginfo-common-s390x 5.14.0-284.11.1.el9_2, +5 more
    fixed: vendor fix RHSA-2023:2458
  • Red Hat Enterprise Linux BaseOS (v. 8) perf 4.18.0-513.5.1.el8_9, kernel 4.18.0-513.5.1.el8_9, bpftool 4.18.0-513.5.1.el8_9, kernel-core 4.18.0-513.5.1.el8_9, kernel-tools 4.18.0-513.5.1.el8_9, python3-perf 4.18.0-513.5.1.el8_9, +15 more
    fixed: vendor fix RHSA-2023:7077
  • Red Hat Enterprise Linux BaseOS (v. 9) bpftool 7.0.0-284.11.1.el9_2, kernel 5.14.0-284.11.1.el9_2, kernel-64k 5.14.0-284.11.1.el9_2, kernel-core 5.14.0-284.11.1.el9_2, kernel-tools 5.14.0-284.11.1.el9_2, python3-perf 5.14.0-284.11.1.el9_2, +28 more
    fixed: vendor fix RHSA-2023:2458
  • Red Hat Enterprise Linux BaseOS EUS (v.8.6) perf 4.18.0-372.64.1.el8_6, kernel 4.18.0-372.64.1.el8_6, bpftool 4.18.0-372.64.1.el8_6, kernel-core 4.18.0-372.64.1.el8_6, kernel-tools 4.18.0-372.64.1.el8_6, python3-perf 4.18.0-372.64.1.el8_6, +15 more
    fixed: vendor fix RHSA-2023:4130
show 3 more
  • Red Hat Enterprise Linux CRB (v. 9) kernel-debuginfo-common-s390x 5.14.0-284.11.1.el9_2, kernel-debuginfo-common-x86_64 5.14.0-284.11.1.el9_2, kernel-debuginfo-common-aarch64 5.14.0-284.11.1.el9_2, kernel-debuginfo-common-ppc64le 5.14.0-284.11.1.el9_2
    fixed: vendor fix RHSA-2023:2458
  • Red Hat Virtualization 4 Hypervisor for RHEL 8 perf 4.18.0-372.64.1.el8_6, kernel-debuginfo-common-x86_64 4.18.0-372.64.1.el8_6
    fixed: vendor fix RHSA-2023:4130
  • Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
9 mo ago

Exploit prediction

0.17% chance of exploitation in the next 30 days, higher than 6% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CISA ADP 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CNA 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Weakness
  • CWE-401 Missing Release of Memory after Effective Lifetime
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.