Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - netschedtcindex_set_parms のメモリリークを修正します Syzkaller は次のようにメモリリークを報告します
    ==================================================================================================== バグ
    comm syz-executor105、pid 3600、jiffies 4294943292 (age 12.990s) hex dump最初の 32 バイト00 00 00 00 00 00 00 00 00 00 00 00 00 0000000000000000000000000000000000000000000000000000000 ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 内のバックトレース[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [インライン] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [インライン] [<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 [インライン] [<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 =============== ============================ カーネルは tcindex_change() を使用して、既存のフィルタープロパティを変更します。
    問題は、変更のプロセス中に「old_r」が「p->perfect」から取得されると、カーネルが tcindex_alloc_performance_hash() を使用してフィルター結果を新たに割り当て、tcindex_filter_result_init() を使用して古いフィルター結果をクリアせず、その tcf_exts 構造体を破壊し、上記のメモリリークを発生させます。より具体的には、tcindex_lookup() によると、「old_r」には 2 つのソースのみがあります。 「old_r」は「p->performance」から取得されるか、「old_r」は「p->h」から取得されます。 * 「old_r」が「p->complete」から取得されると、カーネルは tcindex_alloc_performance_hash() を使用し、フィルター結果を新たに割り当てます。次に「r」が「cp->perfect + handle」で割り当てられ、これは新たに割り当てられます。
    そのため、条件「old_r && old_r != r」はこの状況で真であり、カーネルは tcindex_filter_result_init() を使用して、tcf_exts 構造を破壊せずに、古いフィルター結果をクリアします。* 「old_r」が「p->h」から取得される場合、 「p->perfect」は、tcindex_lookup() によると NULL です。「cp->h」が「p->h」から直接コピーされ、「p->performance」が NULL であることを考慮すると、「r」は「tcindex_lookup(cp, handle)」で割り当てられ、その値は と同じでなければなりません。 「old_r」が「old_r && old_r != r」となるため、カーネルは tcindex_filter_result_init() を使用して古いフィルター結果をクリアすることを無視します。そのため、「old_r」が「p->complete」から取得されるときのみ、カーネルは tcindex_filter_result_init() を使用して古いフィルターの結果をクリアし、これが上記のメモリリークを発生させます。古い tcindex_d を破壊する tc_filter_wq 作業キューがすでに存在することを考慮 ---truncated---CVE-2022-50396

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2022-50396

medium Nessus プラグイン ID 265574

バージョン 1.9