Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report<br /> <br /> It is possible for a malicious device to forgo submitting a Feature<br /> Report. The HID Steam driver presently makes no prevision for this<br /> and de-references the &amp;#39;struct hid_report&amp;#39; pointer obtained from the<br /> HID devices without first checking its validity. Let&amp;#39;s change that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a data-race around bpf_jit_limit.<br /> <br /> While reading bpf_jit_limit, it can be changed concurrently via sysctl,<br /> WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit<br /> is long, so we need to add a paired READ_ONCE() to avoid load-tearing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ieee802154/adf7242: defer destroy_workqueue call<br /> <br /> There is a possible race condition (use-after-free) like below<br /> <br /> (FREE) | (USE)<br /> adf7242_remove | adf7242_channel<br /> cancel_delayed_work_sync |<br /> destroy_workqueue (1) | adf7242_cmd_rx<br /> | mod_delayed_work (2)<br /> |<br /> <br /> The root cause for this race is that the upper layer (ieee802154) is<br /> unaware of this detaching event and the function adf7242_channel can<br /> be called without any checks.<br /> <br /> To fix this, we can add a flag write at the beginning of adf7242_remove<br /> and add flag check in adf7242_channel. Or we can just defer the<br /> destructive operation like other commit 3e0588c291d6 ("hamradio: defer<br /> ax25 kfree after unregister_netdev") which let the<br /> ieee802154_unregister_hw() to handle the synchronization. This patch<br /> takes the second option.<br /> <br /> runs")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: clear optc underflow before turn off odm clock<br /> <br /> [Why]<br /> After ODM clock off, optc underflow bit will be kept there always and clear not work.<br /> We need to clear that before clock off.<br /> <br /> [How]<br /> Clear that if have when clock off.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cgroup: Fix kernel BUG in purge_effective_progs<br /> <br /> Syzkaller reported a triggered kernel BUG as follows:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at kernel/bpf/cgroup.c:925!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0<br /> Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84<br /> 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 0b 48<br /> 8b 0c5<br /> RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578<br /> RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000<br /> R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00<br /> FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> cgroup_bpf_prog_detach+0xcc/0x100<br /> __sys_bpf+0x2273/0x2a00<br /> __x64_sys_bpf+0x17/0x20<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f68214dbcb9<br /> Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89<br /> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01<br /> f0 ff8<br /> RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141<br /> RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9<br /> RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009<br /> RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003<br /> R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20<br /> R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Repetition steps:<br /> <br /> For the following cgroup tree,<br /> <br /> root<br /> |<br /> cg1<br /> |<br /> cg2<br /> <br /> 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs<br /> attach type is NONE or OVERRIDE.<br /> 2. write 1 to /proc/thread-self/fail-nth for failslab.<br /> 3. detach prog1 for cg1, and then kernel BUG occur.<br /> <br /> Failslab injection will cause kmalloc fail and fall back to<br /> purge_effective_progs. The problem is that cg2 have attached another prog,<br /> so when go through cg2 layer, iteration will add pos to 1, and subsequent<br /> operations will be skipped by the following condition, and cg will meet<br /> NULL in the end.<br /> <br /> `if (pos &amp;&amp; !(cg-&gt;bpf.flags[atype] &amp; BPF_F_ALLOW_MULTI))`<br /> <br /> The NULL cg means no link or prog match, this is as expected, and it&amp;#39;s not<br /> a bug. So here just skip the no match situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Fix a potential gpu_metrics_table memory leak<br /> <br /> Memory is allocated for gpu_metrics_table in<br /> smu_v13_0_4_init_smc_tables(), but not freed in<br /> smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix corrupted packets for XDP_SHARED_UMEM<br /> <br /> Fix an issue in XDP_SHARED_UMEM mode together with aligned mode where<br /> packets are corrupted for the second and any further sockets bound to<br /> the same umem. In other words, this does not affect the first socket<br /> bound to the umem. The culprit for this bug is that the initialization<br /> of the DMA addresses for the pre-populated xsk buffer pool entries was<br /> not performed for any socket but the first one bound to the umem. Only<br /> the linear array of DMA addresses was populated. Fix this by populating<br /> the DMA addresses in the xsk buffer pool for every socket bound to the<br /> same umem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: Fix wrong last sg check in sk_msg_recvmsg()<br /> <br /> Fix one kernel NULL pointer dereference as below:<br /> <br /> [ 224.462334] Call Trace:<br /> [ 224.462394] __tcp_bpf_recvmsg+0xd3/0x380<br /> [ 224.462441] ? sock_has_perm+0x78/0xa0<br /> [ 224.462463] tcp_bpf_recvmsg+0x12e/0x220<br /> [ 224.462494] inet_recvmsg+0x5b/0xd0<br /> [ 224.462534] __sys_recvfrom+0xc8/0x130<br /> [ 224.462574] ? syscall_trace_enter+0x1df/0x2e0<br /> [ 224.462606] ? __do_page_fault+0x2de/0x500<br /> [ 224.462635] __x64_sys_recvfrom+0x24/0x30<br /> [ 224.462660] do_syscall_64+0x5d/0x1d0<br /> [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> In commit 9974d37ea75f ("skmsg: Fix invalid last sg check in<br /> sk_msg_recvmsg()"), we change last sg check to sg_is_last(),<br /> but in sockmap redirection case (without stream_parser/stream_verdict/<br /> skb_verdict), we did not mark the end of the scatterlist. Check the<br /> sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all<br /> do not mark the end of sg. They are expected to use sg.end for end<br /> judgment. So the judgment of &amp;#39;(i != msg_rx-&gt;sg.end)&amp;#39; is added back here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: nintendo: fix rumble worker null pointer deref<br /> <br /> We can dereference a null pointer trying to queue work to a destroyed<br /> workqueue.<br /> <br /> If the device is disconnected, nintendo_hid_remove is called, in which<br /> the rumble_queue is destroyed. Avoid using that queue to defer rumble<br /> work once the controller state is set to JOYCON_CTLR_STATE_REMOVED.<br /> <br /> This eliminates the null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Don&amp;#39;t redirect packets with invalid pkt_len<br /> <br /> Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any<br /> skbs, that is, the flow-&gt;head is null.<br /> The root cause, as the [2] says, is because that bpf_prog_test_run_skb()<br /> run a bpf prog which redirects empty skbs.<br /> So we should determine whether the length of the packet modified by bpf<br /> prog or others like bpf_prog_test is valid before forwarding it directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fix netdevice reference leaks in attach_default_qdiscs()<br /> <br /> In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails<br /> to attach qdisc because there is no memory in attach_one_default_qdisc().<br /> Then dev-&gt;qdisc will be noop_qdisc by default. But the other queues may be<br /> able to successfully attach to default qdisc.<br /> <br /> In this case, the fallback to noqueue process will be triggered. If the<br /> original attached qdisc is not released and a new one is directly<br /> attached, this will cause netdevice reference leaks.<br /> <br /> The following is the bug log:<br /> <br /> veth0: default qdisc (fq_codel) fail, fallback to noqueue<br /> unregister_netdevice: waiting for veth0 to become free. Usage count = 32<br /> leaked reference.<br /> qdisc_alloc+0x12e/0x210<br /> qdisc_create_dflt+0x62/0x140<br /> attach_one_default_qdisc.constprop.41+0x44/0x70<br /> dev_activate+0x128/0x290<br /> __dev_open+0x12a/0x190<br /> __dev_change_flags+0x1a2/0x1f0<br /> dev_change_flags+0x23/0x60<br /> do_setlink+0x332/0x1150<br /> __rtnl_newlink+0x52f/0x8e0<br /> rtnl_newlink+0x43/0x70<br /> rtnetlink_rcv_msg+0x140/0x3b0<br /> netlink_rcv_skb+0x50/0x100<br /> netlink_unicast+0x1bb/0x290<br /> netlink_sendmsg+0x37c/0x4e0<br /> sock_sendmsg+0x5f/0x70<br /> ____sys_sendmsg+0x208/0x280<br /> <br /> Fix this bug by clearing any non-noop qdiscs that may have been assigned<br /> before trying to re-attach.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix memory leak at failed datapath creation<br /> <br /> ovs_dp_cmd_new()-&gt;ovs_dp_change()-&gt;ovs_dp_set_upcall_portids()<br /> allocates array via kmalloc.<br /> If for some reason new_vport() fails during ovs_dp_cmd_new()<br /> dp-&gt;upcall_portids must be freed.<br /> Add missing kfree.<br /> <br /> Kmemleak example:<br /> unreferenced object 0xffff88800c382500 (size 64):<br /> comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s)<br /> hex dump (first 32 bytes):<br /> 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8.....<br /> 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(...<br /> backtrace:<br /> [] ovs_dp_set_upcall_portids+0x38/0xa0<br /> [] ovs_dp_change+0x63/0xe0<br /> [] ovs_dp_cmd_new+0x1f0/0x380<br /> [] genl_family_rcv_msg_doit+0xea/0x150<br /> [] genl_rcv_msg+0xdc/0x1e0<br /> [] netlink_rcv_skb+0x50/0x100<br /> [] genl_rcv+0x24/0x40<br /> [] netlink_unicast+0x23e/0x360<br /> [] netlink_sendmsg+0x24e/0x4b0<br /> [] sock_sendmsg+0x62/0x70<br /> [] ____sys_sendmsg+0x230/0x270<br /> [] ___sys_sendmsg+0x88/0xd0<br /> [] __sys_sendmsg+0x59/0xa0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd