Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fail to recover device if queue setup is interrupted<br /> <br /> In ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is<br /> interrupted by signal, queues aren&amp;#39;t setup successfully yet, so we<br /> have to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be<br /> triggered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Load L1&amp;#39;s TSC multiplier based on L1 state, not L2 state<br /> <br /> When emulating nested VM-Exit, load L1&amp;#39;s TSC multiplier if L1&amp;#39;s desired<br /> ratio doesn&amp;#39;t match the current ratio, not if the ratio L1 is using for<br /> L2 diverges from the default. Functionally, the end result is the same<br /> as KVM will run L2 with L1&amp;#39;s multiplier if L2&amp;#39;s multiplier is the default,<br /> i.e. checking that L1&amp;#39;s multiplier is loaded is equivalent to checking if<br /> L2 has a non-default multiplier.<br /> <br /> However, the assertion that TSC scaling is exposed to L1 is flawed, as<br /> userspace can trigger the WARN at will by writing the MSR and then<br /> updating guest CPUID to hide the feature (modifying guest CPUID is<br /> allowed anytime before KVM_RUN). E.g. hacking KVM&amp;#39;s state_test<br /> selftest to do<br /> <br /> vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);<br /> vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);<br /> <br /> after restoring state in a new VM+vCPU yields an endless supply of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105<br /> nested_svm_vmexit+0x6af/0x720 [kvm_amd]<br /> Call Trace:<br /> nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]<br /> svm_handle_exit+0xb9/0x180 [kvm_amd]<br /> kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]<br /> kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]<br /> ? trace_hardirqs_off+0x4d/0xa0<br /> __se_sys_ioctl+0x7a/0xc0<br /> __x64_sys_ioctl+0x21/0x30<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Unlike the nested VMRUN path, hoisting the svm-&gt;tsc_scaling_enabled check<br /> into the if-statement is wrong as KVM needs to ensure L1&amp;#39;s multiplier is<br /> loaded in the above scenario. Alternatively, the WARN_ON() could simply<br /> be deleted, but that would make KVM&amp;#39;s behavior even more subtle, e.g. it&amp;#39;s<br /> not immediately obvious why it&amp;#39;s safe to write MSR_AMD64_TSC_RATIO when<br /> checking only tsc_ratio_msr.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211_hwsim: Fix possible NULL dereference<br /> <br /> In a call to mac80211_hwsim_select_tx_link() the sta pointer might<br /> be NULL, thus need to check that it is not NULL before accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()<br /> <br /> r5l_flush_stripe_to_raid() will check if the list &amp;#39;flushing_ios&amp;#39; is<br /> empty, and then submit &amp;#39;flush_bio&amp;#39;, however, r5l_log_flush_endio()<br /> is clearing the list first and then clear the bio, which will cause<br /> null-ptr-deref:<br /> <br /> T1: submit flush io<br /> raid5d<br /> handle_active_stripes<br /> r5l_flush_stripe_to_raid<br /> // list is empty<br /> // add &amp;#39;io_end_ios&amp;#39; to the list<br /> bio_init<br /> submit_bio<br /> // io1<br /> <br /> T2: io1 is done<br /> r5l_log_flush_endio<br /> list_splice_tail_init<br /> // clear the list<br /> T3: submit new flush io<br /> ...<br /> r5l_flush_stripe_to_raid<br /> // list is empty<br /> // add &amp;#39;io_end_ios&amp;#39; to the list<br /> bio_init<br /> bio_uninit<br /> // clear bio-&gt;bi_blkg<br /> submit_bio<br /> // null-ptr-deref<br /> <br /> Fix this problem by clearing bio before clearing the list in<br /> r5l_log_flush_endio().