{"id":"DEBIAN-CVE-2022-50396","details":"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:     [\u003cffffffff814cf9f0\u003e] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046     [\u003cffffffff839c9e07\u003e] kmalloc include/linux/slab.h:576 [inline]     [\u003cffffffff839c9e07\u003e] kmalloc_array include/linux/slab.h:627 [inline]     [\u003cffffffff839c9e07\u003e] kcalloc include/linux/slab.h:659 [inline]     [\u003cffffffff839c9e07\u003e] tcf_exts_init include/net/pkt_cls.h:250 [inline]     [\u003cffffffff839c9e07\u003e] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342     [\u003cffffffff839caa1f\u003e] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553     [\u003cffffffff8394db62\u003e] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147     [\u003cffffffff8389e91c\u003e] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082     [\u003cffffffff839eba67\u003e] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540     [\u003cffffffff839eab87\u003e] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]     [\u003cffffffff839eab87\u003e] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345     [\u003cffffffff839eb046\u003e] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921     [\u003cffffffff8383e796\u003e] sock_sendmsg_nosec net/socket.c:714 [inline]     [\u003cffffffff8383e796\u003e] sock_sendmsg+0x56/0x80 net/socket.c:734     [\u003cffffffff8383eb08\u003e] ____sys_sendmsg+0x178/0x410 net/socket.c:2482     [\u003cffffffff83843678\u003e] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536     [\u003cffffffff838439c5\u003e] __sys_sendmmsg+0x105/0x330 net/socket.c:2622     [\u003cffffffff83843c14\u003e] __do_sys_sendmmsg net/socket.c:2651 [inline]     [\u003cffffffff83843c14\u003e] __se_sys_sendmmsg net/socket.c:2648 [inline]     [\u003cffffffff83843c14\u003e] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648     [\u003cffffffff84605fd5\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]     [\u003cffffffff84605fd5\u003e] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80     [\u003cffffffff84800087\u003e] 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-\u003eperfect`, 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-\u003eperfect`, or `old_r` is retrieved from `p-\u003eh`.    * If `old_r` is retrieved from `p-\u003eperfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp-\u003eperfect + 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-\u003eh`, then `p-\u003eperfect` is NULL according to the tcindex_lookup(). Considering that `cp-\u003eh` is directly copied from `p-\u003eh` and `p-\u003eperfect` 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-\u003eperfect` 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---","modified":"2026-09-01T16:05:35.043292460Z","published":"2025-09-18T14:15:38.737Z","upstream":["CVE-2022-50396"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2022-50396"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-50396.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-50396.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-50396.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}