Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix use-after-free in chanctx code<br /> <br /> In ieee80211_vif_use_reserved_context(), when we have an<br /> old context and the new context&amp;#39;s replace_state is set to<br /> IEEE80211_CHANCTX_REPLACE_NONE, we free the old context<br /> in ieee80211_vif_use_reserved_reassign(). Therefore, we<br /> cannot check the old_ctx anymore, so we should set it to<br /> NULL after this point.<br /> <br /> However, since the new_ctx replace state is clearly not<br /> IEEE80211_CHANCTX_REPLACES_OTHER, we&amp;#39;re not going to do<br /> anything else in this function and can just return to<br /> avoid accessing the freed old_ctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup<br /> <br /> Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather<br /> than .remove") fixed a use-after-free error due the vesafb driver freeing<br /> the fb_info in the .remove handler instead of doing it in .fb_destroy.<br /> <br /> This can happen if the .fb_destroy callback is executed after the .remove<br /> callback, since the former tries to access a pointer freed by the latter.<br /> <br /> But that change didn&amp;#39;t take into account that another possible scenario is<br /> that .fb_destroy is called before the .remove callback. For example, if no<br /> process has the fbdev chardev opened by the time the driver is removed.<br /> <br /> If that&amp;#39;s the case, fb_info will be freed when unregister_framebuffer() is<br /> called, making the fb_info pointer accessed in vesafb_remove() after that<br /> to no longer be valid.<br /> <br /> To prevent that, move the expression containing the info-&gt;par to happen<br /> before the unregister_framebuffer() function call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: mei: fix potential NULL-ptr deref<br /> <br /> If SKB allocation fails, continue rather than using the NULL<br /> pointer.<br /> <br /> Coverity CID: 1497650

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: annotate races around sk-&gt;sk_bound_dev_if<br /> <br /> UDP sendmsg() is lockless, and reads sk-&gt;sk_bound_dev_if while<br /> this field can be changed by another thread.<br /> <br /> Adds minimal annotations to avoid KCSAN splats for UDP.<br /> Following patches will add more annotations to potential lockless readers.<br /> <br /> BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg<br /> <br /> write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0:<br /> __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221<br /> ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272<br /> inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576<br /> __sys_connect_file net/socket.c:1900 [inline]<br /> __sys_connect+0x197/0x1b0 net/socket.c:1917<br /> __do_sys_connect net/socket.c:1927 [inline]<br /> __se_sys_connect net/socket.c:1924 [inline]<br /> __x64_sys_connect+0x3d/0x50 net/socket.c:1924<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1:<br /> udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436<br /> inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652<br /> sock_sendmsg_nosec net/socket.c:705 [inline]<br /> sock_sendmsg net/socket.c:725 [inline]<br /> ____sys_sendmsg+0x39a/0x510 net/socket.c:2413<br /> ___sys_sendmsg net/socket.c:2467 [inline]<br /> __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553<br /> __do_sys_sendmmsg net/socket.c:2582 [inline]<br /> __se_sys_sendmmsg net/socket.c:2579 [inline]<br /> __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> value changed: 0x00000000 -&gt; 0xffffff9b<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> <br /> I chose to not add Fixes: tag because race has minor consequences<br /> and stable teams busy enough.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup<br /> <br /> of_parse_phandle() returns a node pointer with refcount incremented, we should<br /> use of_node_put() on it when not need anymore. Add missing of_node_put() to<br /> avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix the error handling path in idxd_cdev_register()<br /> <br /> If a call to alloc_chrdev_region() fails, the already allocated resources<br /> are leaking.<br /> <br /> Add the needed error handling path to fix the leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtla: Avoid record NULL pointer dereference<br /> <br /> Fix the following null/deref_null.cocci errors:<br /> ./tools/tracing/rtla/src/osnoise_hist.c:870:31-36: ERROR: record is NULL but dereferenced.<br /> ./tools/tracing/rtla/src/osnoise_top.c:650:31-36: ERROR: record is NULL but dereferenced.<br /> ./tools/tracing/rtla/src/timerlat_hist.c:905:31-36: ERROR: record is NULL but dereferenced.<br /> ./tools/tracing/rtla/src/timerlat_top.c:700:31-36: ERROR: record is NULL but dereferenced.<br /> <br /> "record" is NULL before calling osnoise_init_trace_tool.<br /> Add a tag "out_free" to avoid dereferring a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Fix NULL pointer dereference when printing dev_name<br /> <br /> When larbdev is NULL (in the case I hit, the node is incorrectly set<br /> iommus = ), it will cause device_link_add() fail and<br /> kernel crashes when we try to print dev_name(larbdev).<br /> <br /> Let&amp;#39;s fail the probe if a larbdev is NULL to avoid invalid inputs from<br /> dts.<br /> <br /> It should work for normal correct setting and avoid the crash caused<br /> by my incorrect setting.<br /> <br /> Error log:<br /> [ 18.189042][ T301] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050<br /> ...<br /> [ 18.344519][ T301] pstate: a0400005 (NzCv daif +PAN -UAO)<br /> [ 18.345213][ T301] pc : mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu]<br /> [ 18.346050][ T301] lr : mtk_iommu_probe_device+0xd0/0x118 [mtk_iommu]<br /> [ 18.346884][ T301] sp : ffffffc00a5635e0<br /> [ 18.347392][ T301] x29: ffffffc00a5635e0 x28: ffffffd44a46c1d8<br /> [ 18.348156][ T301] x27: ffffff80c39a8000 x26: ffffffd44a80cc38<br /> [ 18.348917][ T301] x25: 0000000000000000 x24: ffffffd44a80cc38<br /> [ 18.349677][ T301] x23: ffffffd44e4da4c6 x22: ffffffd44a80cc38<br /> [ 18.350438][ T301] x21: ffffff80cecd1880 x20: 0000000000000000<br /> [ 18.351198][ T301] x19: ffffff80c439f010 x18: ffffffc00a50d0c0<br /> [ 18.351959][ T301] x17: ffffffffffffffff x16: 0000000000000004<br /> [ 18.352719][ T301] x15: 0000000000000004 x14: ffffffd44eb5d420<br /> [ 18.353480][ T301] x13: 0000000000000ad2 x12: 0000000000000003<br /> [ 18.354241][ T301] x11: 00000000fffffad2 x10: c0000000fffffad2<br /> [ 18.355003][ T301] x9 : a0d288d8d7142d00 x8 : a0d288d8d7142d00<br /> [ 18.355763][ T301] x7 : ffffffd44c2bc640 x6 : 0000000000000000<br /> [ 18.356524][ T301] x5 : 0000000000000080 x4 : 0000000000000001<br /> [ 18.357284][ T301] x3 : 0000000000000000 x2 : 0000000000000005<br /> [ 18.358045][ T301] x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 18.360208][ T301] Hardware name: MT6873 (DT)<br /> [ 18.360771][ T301] Call trace:<br /> [ 18.361168][ T301] dump_backtrace+0xf8/0x1f0<br /> [ 18.361737][ T301] dump_stack_lvl+0xa8/0x11c<br /> [ 18.362305][ T301] dump_stack+0x1c/0x2c<br /> [ 18.362816][ T301] mrdump_common_die+0x184/0x40c [mrdump]<br /> [ 18.363575][ T301] ipanic_die+0x24/0x38 [mrdump]<br /> [ 18.364230][ T301] atomic_notifier_call_chain+0x128/0x2b8<br /> [ 18.364937][ T301] die+0x16c/0x568<br /> [ 18.365394][ T301] __do_kernel_fault+0x1e8/0x214<br /> [ 18.365402][ T301] do_page_fault+0xb8/0x678<br /> [ 18.366934][ T301] do_translation_fault+0x48/0x64<br /> [ 18.368645][ T301] do_mem_abort+0x68/0x148<br /> [ 18.368652][ T301] el1_abort+0x40/0x64<br /> [ 18.368660][ T301] el1h_64_sync_handler+0x54/0x88<br /> [ 18.368668][ T301] el1h_64_sync+0x68/0x6c<br /> [ 18.368673][ T301] mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix dereference of stale list iterator after loop body<br /> <br /> The list iterator variable will be a bogus pointer if no break was hit.<br /> Dereferencing it (cur-&gt;page in this case) could load an out-of-bounds/undefined<br /> value making it unsafe to use that in the comparision to determine if the<br /> specific element was found.<br /> <br /> Since &amp;#39;cur-&gt;page&amp;#39; *can* be out-ouf-bounds it cannot be guaranteed that<br /> by chance (or intention of an attacker) it matches the value of &amp;#39;page&amp;#39;<br /> even though the correct element was not found.<br /> <br /> This is fixed by using a separate list iterator variable for the loop<br /> and only setting the original variable if a suitable element was found.<br /> Then determing if the element was found is simply checking if the<br /> variable is set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix free of uninitialized nfs4_label on referral lookup.<br /> <br /> Send along the already-allocated fattr along with nfs4_fs_locations, and<br /> drop the memcpy of fattr. We end up growing two more allocations, but this<br /> fixes up a crash as:<br /> <br /> PID: 790 TASK: ffff88811b43c000 CPU: 0 COMMAND: "ls"<br /> #0 [ffffc90000857920] panic at ffffffff81b9bfde<br /> #1 [ffffc900008579c0] do_trap at ffffffff81023a9b<br /> #2 [ffffc90000857a10] do_error_trap at ffffffff81023b78<br /> #3 [ffffc90000857a58] exc_stack_segment at ffffffff81be1f45<br /> #4 [ffffc90000857a80] asm_exc_stack_segment at ffffffff81c009de<br /> #5 [ffffc90000857b08] nfs_lookup at ffffffffa0302322 [nfs]<br /> #6 [ffffc90000857b70] __lookup_slow at ffffffff813a4a5f<br /> #7 [ffffc90000857c60] walk_component at ffffffff813a86c4<br /> #8 [ffffc90000857cb8] path_lookupat at ffffffff813a9553<br /> #9 [ffffc90000857cf0] filename_lookup at ffffffff813ab86b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: Update cgroup information before merging bio<br /> <br /> When the process is migrated to a different cgroup (or in case of<br /> writeback just starts submitting bios associated with a different<br /> cgroup) bfq_merge_bio() can operate with stale cgroup information in<br /> bic. Thus the bio can be merged to a request from a different cgroup or<br /> it can result in merging of bfqqs for different cgroups or bfqqs of<br /> already dead cgroups and causing possible use-after-free issues. Fix the<br /> problem by updating cgroup information in bfq_merge_bio().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: Make sure bfqg for which we are queueing requests is online<br /> <br /> Bios queued into BFQ IO scheduler can be associated with a cgroup that<br /> was already offlined. This may then cause insertion of this bfq_group<br /> into a service tree. But this bfq_group will get freed as soon as last<br /> bio associated with it is completed leading to use after free issues for<br /> service tree users. Fix the problem by making sure we always operate on<br /> online bfq_group. If the bfq_group associated with the bio is not<br /> online, we pick the first online parent.