Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta<br /> <br /> Avoid potential data corruption issues caused by uninitialized driver<br /> private data structures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix warning in cifs_smb3_do_mount()<br /> <br /> This fixes the following warning reported by kernel test robot<br /> <br /> fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible<br /> memory leak of &amp;#39;cifs_sb&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid potential memory corruption in __update_iostat_latency()<br /> <br /> Add iotype sanity check to avoid potential memory corruption.<br /> This is to fix the compile error below:<br /> <br /> fs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow<br /> &amp;#39;io_lat-&gt;peak_lat[type]&amp;#39; 3 type;<br /> 216 struct f2fs_sb_info *sbi = iostat_ctx-&gt;sbi;<br /> 217 struct iostat_lat_info *io_lat = sbi-&gt;iostat_io_lat;<br /> 218 unsigned long flags;<br /> 219<br /> 220 if (!sbi-&gt;iostat_enable)<br /> 221 return;<br /> 222<br /> 223 ts_diff = jiffies - iostat_ctx-&gt;submit_ts;<br /> 224 if (page_type &gt;= META_FLUSH)<br /> ^^^^^^^^^^<br /> <br /> 225 page_type = META;<br /> 226<br /> 227 spin_lock_irqsave(&amp;sbi-&gt;iostat_lat_lock, flags);<br /> @228 io_lat-&gt;sum_lat[type][page_type] += ts_diff;<br /> ^^^^^^^^^<br /> Mixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Don&amp;#39;t balance task to its current running CPU<br /> <br /> We&amp;#39;ve run into the case that the balancer tries to balance a migration<br /> disabled task and trigger the warning in set_task_cpu() like below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240<br /> Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <br /> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1<br /> Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : set_task_cpu+0x188/0x240<br /> lr : load_balance+0x5d0/0xc60<br /> sp : ffff80000803bc70<br /> x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040<br /> x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001<br /> x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78<br /> x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000<br /> x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000<br /> x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530<br /> x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e<br /> x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a<br /> x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001<br /> Call trace:<br /> set_task_cpu+0x188/0x240<br /> load_balance+0x5d0/0xc60<br /> rebalance_domains+0x26c/0x380<br /> _nohz_idle_balance.isra.0+0x1e0/0x370<br /> run_rebalance_domains+0x6c/0x80<br /> __do_softirq+0x128/0x3d8<br /> ____do_softirq+0x18/0x24<br /> call_on_irq_stack+0x2c/0x38<br /> do_softirq_own_stack+0x24/0x3c<br /> __irq_exit_rcu+0xcc/0xf4<br /> irq_exit_rcu+0x18/0x24<br /> el1_interrupt+0x4c/0xe4<br /> el1h_64_irq_handler+0x18/0x2c<br /> el1h_64_irq+0x74/0x78<br /> arch_cpu_idle+0x18/0x4c<br /> default_idle_call+0x58/0x194<br /> do_idle+0x244/0x2b0<br /> cpu_startup_entry+0x30/0x3c<br /> secondary_start_kernel+0x14c/0x190<br /> __secondary_switched+0xb0/0xb4<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Further investigation shows that the warning is superfluous, the migration<br /> disabled task is just going to be migrated to its current running CPU.<br /> This is because that on load balance if the dst_cpu is not allowed by the<br /> task, we&amp;#39;ll re-select a new_dst_cpu as a candidate. If no task can be<br /> balanced to dst_cpu we&amp;#39;ll try to balance the task to the new_dst_cpu<br /> instead. In this case when the migration disabled task is not on CPU it<br /> only allows to run on its current CPU, load balance will select its<br /> current CPU as new_dst_cpu and later triggers the warning above.<br /> <br /> The new_dst_cpu is chosen from the env-&gt;dst_grpmask. Currently it<br /> contains CPUs in sched_group_span() and if we have overlapped groups it&amp;#39;s<br /> possible to run into this case. This patch makes env-&gt;dst_grpmask of<br /> group_balance_mask() which exclude any CPUs from the busiest group and<br /> solve the issue. For balancing in a domain with no overlapped groups<br /> the behaviour keeps same as before.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: efi: Make efi_rt_lock a raw_spinlock<br /> <br /> Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs<br /> the following:<br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 3 locks held by kworker/u320:0/9:<br /> #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)<br /> #1: ffff80000861bdd0 ((work_completion)(&amp;efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)<br /> #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)<br /> Preemption disabled at:<br /> efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248)<br /> CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1<br /> Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18<br /> Workqueue: efi_rts_wq efi_call_rts<br /> Call trace:<br /> dump_backtrace (arch/arm64/kernel/stacktrace.c:158)<br /> show_stack (arch/arm64/kernel/stacktrace.c:165)<br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))<br /> dump_stack (lib/dump_stack.c:114)<br /> __might_resched (kernel/sched/core.c:10134)<br /> rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4))<br /> efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)<br /> [...]<br /> <br /> This seems to come from commit ff7a167961d1 ("arm64: efi: Execute<br /> runtime services from a dedicated stack") which adds a spinlock. This<br /> spinlock is taken through:<br /> efi_call_rts()<br /> \-efi_call_virt()<br /> \-efi_call_virt_pointer()<br /> \-arch_efi_call_virt_setup()<br /> <br /> Make &amp;#39;efi_rt_lock&amp;#39; a raw_spinlock to avoid being preempted.<br /> <br /> [ardb: The EFI runtime services are called with a different set of<br /> translation tables, and are permitted to use the SIMD registers.<br /> The context switch code preserves/restores neither, and so EFI<br /> calls must be made with preemption disabled, rather than only<br /> disabling migration.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nubus: Partially revert proc_create_single_data() conversion<br /> <br /> The conversion to proc_create_single_data() introduced a regression<br /> whereby reading a file in /proc/bus/nubus results in a seg fault:<br /> <br /> # grep -r . /proc/bus/nubus/e/<br /> Data read fault at 0x00000020 in Super Data (pc=0x1074c2)<br /> BAD KERNEL BUSERR<br /> Oops: 00000000<br /> Modules linked in:<br /> PC: [] PDE_DATA+0xc/0x16<br /> SR: 2010 SP: 38284958 a2: 01152370<br /> d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000<br /> d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40<br /> Process grep (pid: 45, task=142f8727)<br /> Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70<br /> baddr=001074c8 dibuf=ffffffff ver=f<br /> Stack from 01199e48:<br /> 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000<br /> 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000<br /> d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000<br /> 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640<br /> 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c<br /> 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0<br /> Call Trace: [] nubus_proc_rsrc_show+0x18/0xa0<br /> [] seq_read+0xc4/0x510<br /> [] fp_fcos+0x2/0x82<br /> [] __sys_setreuid+0x115/0x1c6<br /> [] proc_reg_read+0x5c/0xb0<br /> [] fp_fcos+0x2/0x82<br /> [] __vfs_read+0x2c/0x13c<br /> [] fp_fcos+0x2/0x82<br /> [] fp_fcos+0x2/0x82<br /> [] sys_statx+0x60/0x7e<br /> [] vfs_read+0x62/0x12a<br /> [] fp_fcos+0x2/0x82<br /> [] fp_fcos+0x2/0x82<br /> [] ksys_read+0x48/0xbe<br /> [] fp_fcos+0x2/0x82<br /> [] sys_read+0x16/0x1a<br /> [] fp_fcos+0x2/0x82<br /> [] syscall+0x8/0xc<br /> [] fp_fcos+0x2/0x82<br /> [] not_ext+0xa/0x18<br /> Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8<br /> Disabling lock debugging due to kernel taint<br /> <br /> Segmentation fault<br /> <br /> The proc_create_single_data() conversion does not work because<br /> single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not<br /> equivalent to the original code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Make it so that a waiting process can be aborted<br /> <br /> When sendmsg() creates an rxrpc call, it queues it to wait for a connection<br /> and channel to be assigned and then waits before it can start shovelling<br /> data as the encrypted DATA packet content includes a summary of the<br /> connection parameters.<br /> <br /> However, sendmsg() may get interrupted before a connection gets assigned<br /> and further sendmsg() calls will fail with EBUSY until an assignment is<br /> made.<br /> <br /> Fix this so that the call can at least be aborted without failing on<br /> EBUSY. We have to be careful here as sendmsg() mustn&amp;#39;t be allowed to start<br /> the call timer if the call doesn&amp;#39;t yet have a connection assigned as an<br /> oops may follow shortly thereafter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: netup_unidvb: fix use-after-free at del_timer()<br /> <br /> When Universal DVB card is detaching, netup_unidvb_dma_fini()<br /> uses del_timer() to stop dma-&gt;timeout timer. But when timer<br /> handler netup_unidvb_dma_timeout() is running, del_timer()<br /> could not stop it. As a result, the use-after-free bug could<br /> happen. The process is shown below:<br /> <br /> (cleanup routine) | (timer routine)<br /> | mod_timer(&amp;dev-&gt;tx_sim_timer, ..)<br /> netup_unidvb_finidev() | (wait a time)<br /> netup_unidvb_dma_fini() | netup_unidvb_dma_timeout()<br /> del_timer(&amp;dma-&gt;timeout); |<br /> | ndev-&gt;pci_dev-&gt;dev //USE<br /> <br /> Fix by changing del_timer() to del_timer_sync().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()<br /> <br /> In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach az6007_i2c_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix memleak due to fentry attach failure<br /> <br /> If it fails to attach fentry, the allocated bpf trampoline image will be<br /> left in the system. That can be verified by checking /proc/kallsyms.<br /> <br /> This meamleak can be verified by a simple bpf program as follows:<br /> <br /> SEC("fentry/trap_init")<br /> int fentry_run()<br /> {<br /> return 0;<br /> }<br /> <br /> It will fail to attach trap_init because this function is freed after<br /> kernel init, and then we can find the trampoline image is left in the<br /> system by checking /proc/kallsyms.<br /> <br /> $ tail /proc/kallsyms<br /> ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf]<br /> ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]<br /> <br /> $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC &amp;#39;trap_init&amp;#39;"<br /> [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static<br /> <br /> $ echo $((6442453466 &amp; 0x7fffffff))<br /> 2522<br /> <br /> Note that there are two left bpf trampoline images, that is because the<br /> libbpf will fallback to raw tracepoint if -EINVAL is returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: jfs_dmap: Validate db_l2nbperpage while mounting<br /> <br /> In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block<br /> number inside dbFree(). db_l2nbperpage, which is the log2 number of<br /> blocks per page, is passed as an argument to BLKTODMAP which uses it<br /> for shifting.<br /> <br /> Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is<br /> too big. This happens because the large value is set without any<br /> validation in dbMount() at line 181.<br /> <br /> Thus, make sure that db_l2nbperpage is correct while mounting.<br /> <br /> Max number of blocks per page = Page size / Min block size<br /> =&gt; log2(Max num_block per page) = log2(Page size / Min block size)<br /> = log2(Page size) - log2(Min block size)<br /> <br /> =&gt; Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE

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