Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: free raw_report buffers in usbhid_stop<br /> <br /> Free the unsent raw_report buffers when the device is removed.<br /> <br /> Fixes a memory leak reported by syzbot at:<br /> https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add error checking to ext4_ext_replay_set_iblocks()<br /> <br /> If the call to ext4_map_blocks() fails due to an corrupted file<br /> system, ext4_ext_replay_set_iblocks() can get stuck in an infinite<br /> loop. This could be reproduced by running generic/526 with a file<br /> system that has inline_data and fast_commit enabled. The system will<br /> repeatedly log to the console:<br /> <br /> EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 &gt; max in inode 131076<br /> <br /> and the stack that it gets stuck in is:<br /> <br /> ext4_block_to_path+0xe3/0x130<br /> ext4_ind_map_blocks+0x93/0x690<br /> ext4_map_blocks+0x100/0x660<br /> skip_hole+0x47/0x70<br /> ext4_ext_replay_set_iblocks+0x223/0x440<br /> ext4_fc_replay_inode+0x29e/0x3b0<br /> ext4_fc_replay+0x278/0x550<br /> do_one_pass+0x646/0xc10<br /> jbd2_journal_recover+0x14a/0x270<br /> jbd2_journal_load+0xc4/0x150<br /> ext4_load_journal+0x1f3/0x490<br /> ext4_fill_super+0x22d4/0x2c00<br /> <br /> With this patch, generic/526 still fails, but system is no longer<br /> locking up in a tight loop. It&amp;#39;s likely the root casue is that<br /> fast_commit replay is corrupting file systems with inline_data, and we<br /> probably need to add better error handling in the fast commit replay<br /> code path beyond what is done here, which essentially just breaks the<br /> infinite loop without reporting the to the higher levels of the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Handle SRCU initialization failure during page track init<br /> <br /> Check the return of init_srcu_struct(), which can fail due to OOM, when<br /> initializing the page track mechanism. Lack of checking leads to a NULL<br /> pointer deref found by a modified syzkaller.<br /> <br /> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: serialize hash resizes and cleanups<br /> <br /> Syzbot was able to trigger the following warning [1]<br /> <br /> No repro found by syzbot yet but I was able to trigger similar issue<br /> by having 2 scripts running in parallel, changing conntrack hash sizes,<br /> and:<br /> <br /> for j in `seq 1 1000` ; do unshare -n /bin/true &gt;/dev/null ; done<br /> <br /> It would take more than 5 minutes for net_namespace structures<br /> to be cleaned up.<br /> <br /> This is because nf_ct_iterate_cleanup() has to restart everytime<br /> a resize happened.<br /> <br /> By adding a mutex, we can serialize hash resizes and cleanups<br /> and also make get_next_corpse() faster by skipping over empty<br /> buckets.<br /> <br /> Even without resizes in the picture, this patch considerably<br /> speeds up network namespace dismantles.<br /> <br /> [1]<br /> INFO: task syz-executor.0:8312 can&amp;#39;t die for more than 144 seconds.<br /> task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006<br /> Call Trace:<br /> context_switch kernel/sched/core.c:4955 [inline]<br /> __schedule+0x940/0x26f0 kernel/sched/core.c:6236<br /> preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408<br /> preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35<br /> __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390<br /> local_bh_enable include/linux/bottom_half.h:32 [inline]<br /> get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]<br /> nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275<br /> nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469<br /> ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171<br /> setup_net+0x639/0xa30 net/core/net_namespace.c:349<br /> copy_net_ns+0x319/0x760 net/core/net_namespace.c:470<br /> create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226<br /> ksys_unshare+0x445/0x920 kernel/fork.c:3128<br /> __do_sys_unshare kernel/fork.c:3202 [inline]<br /> __se_sys_unshare kernel/fork.c:3200 [inline]<br /> __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200<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+0x44/0xae<br /> RIP: 0033:0x7f63da68e739<br /> RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000<br /> RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80<br /> R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000<br /> <br /> Showing all locks held in the system:<br /> 1 lock held by khungtaskd/27:<br /> #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446<br /> 2 locks held by kworker/u4:2/153:<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268<br /> #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272<br /> 1 lock held by systemd-udevd/2970:<br /> 1 lock held by in:imklog/6258:<br /> #0: ffff88807f970ff0 (&amp;f-&gt;f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990<br /> 3 locks held by kworker/1:6/8158:<br /> 1 lock held by syz-executor.0/8312:<br /> 2 locks held by kworker/u4:13/9320:<br /> 1 lock held by<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix svm_migrate_fini warning<br /> <br /> Device manager releases device-specific resources when a driver<br /> disconnects from a device, devm_memunmap_pages and<br /> devm_release_mem_region calls in svm_migrate_fini are redundant.<br /> <br /> It causes below warning trace after patch "drm/amdgpu: Split<br /> amdgpu_device_fini into early and late", so remove function<br /> svm_migrate_fini.<br /> <br /> BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718<br /> <br /> WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795<br /> devm_release_action+0x51/0x60<br /> Call Trace:<br /> ? memunmap_pages+0x360/0x360<br /> svm_migrate_fini+0x2d/0x60 [amdgpu]<br /> kgd2kfd_device_exit+0x23/0xa0 [amdgpu]<br /> amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu]<br /> amdgpu_device_fini_sw+0x45/0x290 [amdgpu]<br /> amdgpu_driver_release_kms+0x12/0x30 [amdgpu]<br /> drm_dev_release+0x20/0x40 [drm]<br /> release_nodes+0x196/0x1e0<br /> device_release_driver_internal+0x104/0x1d0<br /> driver_detach+0x47/0x90<br /> bus_remove_driver+0x7a/0xd0<br /> pci_unregister_driver+0x3d/0x90<br /> amdgpu_exit+0x11/0x20 [amdgpu]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: chipidea: ci_hdrc_imx: Also search for &amp;#39;phys&amp;#39; phandle<br /> <br /> When passing &amp;#39;phys&amp;#39; in the devicetree to describe the USB PHY phandle<br /> (which is the recommended way according to<br /> Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the<br /> following NULL pointer dereference is observed on i.MX7 and i.MX8MM:<br /> <br /> [ 1.489344] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098<br /> [ 1.498170] Mem abort info:<br /> [ 1.500966] ESR = 0x96000044<br /> [ 1.504030] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1.509356] SET = 0, FnV = 0<br /> [ 1.512416] EA = 0, S1PTW = 0<br /> [ 1.515569] FSC = 0x04: level 0 translation fault<br /> [ 1.520458] Data abort info:<br /> [ 1.523349] ISV = 0, ISS = 0x00000044<br /> [ 1.527196] CM = 0, WnR = 1<br /> [ 1.530176] [0000000000000098] user address but active_mm is swapper<br /> [ 1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP<br /> [ 1.542125] Modules linked in:<br /> [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3<br /> [ 1.551901] Hardware name: Kontron i.MX8MM N801X S (DT)<br /> [ 1.557133] Workqueue: events_unbound deferred_probe_work_func<br /> [ 1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)<br /> [ 1.568998] pc : imx7d_charger_detection+0x3f0/0x510<br /> [ 1.573973] lr : imx7d_charger_detection+0x22c/0x510<br /> <br /> This happens because the charger functions check for the phy presence<br /> inside the imx_usbmisc_data structure (data-&gt;usb_phy), but the chipidea<br /> core populates the usb_phy passed via &amp;#39;phys&amp;#39; inside &amp;#39;struct ci_hdrc&amp;#39;<br /> (ci-&gt;usb_phy) instead.<br /> <br /> This causes the NULL pointer dereference inside imx7d_charger_detection().<br /> <br /> Fix it by also searching for &amp;#39;phys&amp;#39; in case &amp;#39;fsl,usbphy&amp;#39; is not found.<br /> <br /> Tested on a imx7s-warp board.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Flush current cpu icache before other cpus<br /> <br /> On SiFive Unmatched, I recently fell onto the following BUG when booting:<br /> <br /> [ 0.000000] ftrace: allocating 36610 entries in 144 pages<br /> [ 0.000000] Oops - illegal instruction [#1]<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5<br /> [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT)<br /> [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae<br /> [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a<br /> [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10<br /> [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000<br /> [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60<br /> [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10<br /> [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43<br /> [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000<br /> [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001<br /> [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000<br /> [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008<br /> [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188<br /> [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002<br /> [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae<br /> [ 0.000000] [] sbi_remote_fence_i+0x1e/0x26<br /> [ 0.000000] [] flush_icache_all+0x12/0x1a<br /> [ 0.000000] [] patch_text_nosync+0x26/0x32<br /> [ 0.000000] [] ftrace_init_nop+0x52/0x8c<br /> [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/0x360<br /> [ 0.000000] [] ftrace_init+0x80/0x130<br /> [ 0.000000] [] start_kernel+0x5c4/0x8f6<br /> [ 0.000000] ---[ end trace f67eb9af4d8d492b ]---<br /> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!<br /> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---<br /> <br /> While ftrace is looping over a list of addresses to patch, it always failed<br /> when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the<br /> backtrace, the illegal instruction is encountered in this same function.<br /> However, patch_text_nosync, after patching the instructions, calls<br /> flush_icache_range. But looking at what happens in this function:<br /> <br /> flush_icache_range -&gt; flush_icache_all<br /> -&gt; sbi_remote_fence_i<br /> -&gt; __sbi_rfence_v02<br /> -&gt; riscv_cpuid_to_hartid_mask<br /> <br /> The icache and dcache of the current cpu are never synchronized between the<br /> patching of riscv_cpuid_to_hartid_mask and calling this same function.<br /> <br /> So fix this by flushing the current cpu&amp;#39;s icache before asking for the other<br /> cpus to do the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: mvm: Fix possible NULL dereference<br /> <br /> In __iwl_mvm_remove_time_event() check that &amp;#39;te_data-&gt;vif&amp;#39; is NULL<br /> before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t call rq_qos_ops-&gt;done_bio if the bio isn&amp;#39;t tracked<br /> <br /> rq_qos framework is only applied on request based driver, so:<br /> <br /> 1) rq_qos_done_bio() needn&amp;#39;t to be called for bio based driver<br /> <br /> 2) rq_qos_done_bio() needn&amp;#39;t to be called for bio which isn&amp;#39;t tracked,<br /> such as bios ended from error handling code.<br /> <br /> Especially in bio_endio():<br /> <br /> 1) request queue is referred via bio-&gt;bi_bdev-&gt;bd_disk-&gt;queue, which<br /> may be gone since request queue refcount may not be held in above two<br /> cases<br /> <br /> 2) q-&gt;rq_qos may be freed in blk_cleanup_queue() when calling into<br /> __rq_qos_done_bio()<br /> <br /> Fix the potential kernel panic by not calling rq_qos_ops-&gt;done_bio if<br /> the bio isn&amp;#39;t tracked. This way is safe because both ioc_rqos_done_bio()<br /> and blkcg_iolatency_done_bio() are nop if the bio isn&amp;#39;t tracked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb<br /> <br /> We should always check if skb_header_pointer&amp;#39;s return is NULL before<br /> using it, otherwise it may cause null-ptr-deref, as syzbot reported:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]<br /> RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196<br /> Call Trace:<br /> <br /> sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109<br /> ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422<br /> ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463<br /> NF_HOOK include/linux/netfilter.h:307 [inline]<br /> NF_HOOK include/linux/netfilter.h:301 [inline]<br /> ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472<br /> dst_input include/net/dst.h:460 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]<br /> NF_HOOK include/linux/netfilter.h:307 [inline]<br /> NF_HOOK include/linux/netfilter.h:301 [inline]<br /> ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297