Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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()")

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: location: Free struct acpi_pld_info *pld before return false<br /> <br /> struct acpi_pld_info *pld should be freed before the return of allocation<br /> failure, to prevent memory leak, add the ACPI_FREE() to fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()<br /> <br /> Fix a slab-out-of-bounds read that occurs in kmemdup() called from<br /> brcmf_get_assoc_ies().<br /> The bug could occur when assoc_info-&gt;req_len, data from a URB provided<br /> by a USB device, is bigger than the size of buffer which is defined as<br /> WL_EXTRA_BUF_MAX.<br /> <br /> Add the size check for req_len/resp_len of assoc_info.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> [ 46.592467][ T7] ==================================================================<br /> [ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50<br /> [ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7<br /> [ 46.598575][ T7]<br /> [ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145<br /> [ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> [ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker<br /> [ 46.605943][ T7] Call Trace:<br /> [ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1<br /> [ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334<br /> [ 46.608610][ T7] ? kmemdup+0x3e/0x50<br /> [ 46.609341][ T7] kasan_report.cold+0x79/0xd5<br /> [ 46.610151][ T7] ? kmemdup+0x3e/0x50<br /> [ 46.610796][ T7] kasan_check_range+0x14e/0x1b0<br /> [ 46.611691][ T7] memcpy+0x20/0x60<br /> [ 46.612323][ T7] kmemdup+0x3e/0x50<br /> [ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60<br /> [ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0<br /> [ 46.614831][ T7] ? lock_chain_count+0x20/0x20<br /> [ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770<br /> [ 46.616552][ T7] ? lock_chain_count+0x20/0x20<br /> [ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770<br /> [ 46.618244][ T7] ? lock_chain_count+0x20/0x20<br /> [ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0<br /> [ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0<br /> [ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790<br /> [ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950<br /> [ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0<br /> [ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0<br /> [ 46.623390][ T7] ? find_held_lock+0x2d/0x110<br /> [ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60<br /> [ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0<br /> [ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0<br /> [ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0<br /> [ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100<br /> [ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60<br /> [ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100<br /> [ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0<br /> [ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0<br /> [ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> [ 46.630649][ T7] process_one_work+0x92b/0x1460<br /> [ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330<br /> [ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90<br /> [ 46.632347][ T7] worker_thread+0x95/0xe00<br /> [ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0<br /> [ 46.633393][ T7] ? process_one_work+0x1460/0x1460<br /> [ 46.633957][ T7] kthread+0x3a1/0x480<br /> [ 46.634369][ T7] ? set_kthread_struct+0x120/0x120<br /> [ 46.634933][ T7] ret_from_fork+0x1f/0x30<br /> [ 46.635431][ T7]<br /> [ 46.635687][ T7] Allocated by task 7:<br /> [ 46.636151][ T7] kasan_save_stack+0x1b/0x40<br /> [ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90<br /> [ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330<br /> [ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040<br /> [ 46.638275][ T7] brcmf_attach+0x389/0xd40<br /> [ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690<br /> [ 46.639279][ T7] usb_probe_interface+0x2aa/0x760<br /> [ 46.639820][ T7] really_probe+0x205/0xb70<br /> [ 46.640342][ T7] __driver_probe_device+0<br /> ---truncated---