CVE-2022-50396

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix memory leak in tcindex_set_parms<br /> <br /> Syzkaller reports a memory leak as follows:<br /> ====================================<br /> BUG: memory leak<br /> unreferenced object 0xffff88810c287f00 (size 256):<br /> comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046<br /> [] kmalloc include/linux/slab.h:576 [inline]<br /> [] kmalloc_array include/linux/slab.h:627 [inline]<br /> [] kcalloc include/linux/slab.h:659 [inline]<br /> [] tcf_exts_init include/net/pkt_cls.h:250 [inline]<br /> [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342<br /> [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553<br /> [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147<br /> [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082<br /> [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345<br /> [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921<br /> [] sock_sendmsg_nosec net/socket.c:714 [inline]<br /> [] sock_sendmsg+0x56/0x80 net/socket.c:734<br /> [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482<br /> [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536<br /> [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622<br /> [] __do_sys_sendmmsg net/socket.c:2651 [inline]<br /> [] __se_sys_sendmmsg net/socket.c:2648 [inline]<br /> [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ====================================<br /> <br /> Kernel uses tcindex_change() to change an existing<br /> filter properties.<br /> <br /> Yet the problem is that, during the process of changing,<br /> if `old_r` is retrieved from `p-&gt;perfect`, then<br /> kernel uses tcindex_alloc_perfect_hash() to newly<br /> allocate filter results, uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure, which triggers the above memory leak.<br /> <br /> To be more specific, there are only two source for the `old_r`,<br /> according to the tcindex_lookup(). `old_r` is retrieved from<br /> `p-&gt;perfect`, or `old_r` is retrieved from `p-&gt;h`.<br /> <br /> * If `old_r` is retrieved from `p-&gt;perfect`, kernel uses<br /> tcindex_alloc_perfect_hash() to newly allocate the<br /> filter results. Then `r` is assigned with `cp-&gt;perfect + handle`,<br /> which is newly allocated. So condition `old_r &amp;&amp; old_r != r` is<br /> true in this situation, and kernel uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure<br /> <br /> * If `old_r` is retrieved from `p-&gt;h`, then `p-&gt;perfect` is NULL<br /> according to the tcindex_lookup(). Considering that `cp-&gt;h`<br /> is directly copied from `p-&gt;h` and `p-&gt;perfect` is NULL,<br /> `r` is assigned with `tcindex_lookup(cp, handle)`, whose value<br /> should be the same as `old_r`, so condition `old_r &amp;&amp; old_r != r`<br /> is false in this situation, kernel ignores using<br /> tcindex_filter_result_init() to clear the old filter result.<br /> <br /> So only when `old_r` is retrieved from `p-&gt;perfect` does kernel use<br /> tcindex_filter_result_init() to clear the old filter result, which<br /> triggers the above memory leak.<br /> <br /> Considering that there already exists a tc_filter_wq workqueue<br /> to destroy the old tcindex_d<br /> ---truncated---