Vulnerabilidades

*** 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---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus_core) Fix NULL pointer dereference<br /> <br /> Pass i2c_client to _pmbus_is_enabled to drop the assumption<br /> that a regulator device is passed in.<br /> <br /> This will fix the issue of a NULL pointer dereference when called from<br /> _pmbus_get_flags.

*** 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 /> ocxl: fix pci device refcount leak when calling get_function_0()<br /> <br /> get_function_0() calls pci_get_domain_bus_and_slot(), as comment<br /> says, it returns a pci device with refcount increment, so after<br /> using it, pci_dev_put() needs be called.<br /> <br /> Get the device reference when get_function_0() is not called, so<br /> pci_dev_put() can be called in the error path and callers<br /> unconditionally. And add comment above get_dvsec_vendor0() to tell<br /> callers to call pci_dev_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler<br /> <br /> We do check for target CPU == -1, but this might change at the time we<br /> are going to use it. Hold the physical target CPU in a local variable to<br /> avoid out-of-bound accesses to the cpu arrays.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix data-races around user-&gt;unix_inflight.<br /> <br /> user-&gt;unix_inflight is changed under spin_lock(unix_gc_lock),<br /> but too_many_unix_fds() reads it locklessly.<br /> <br /> Let&amp;#39;s annotate the write/read accesses to user-&gt;unix_inflight.<br /> <br /> BUG: KCSAN: data-race in unix_attach_fds / unix_inflight<br /> <br /> write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:<br /> unix_inflight+0x157/0x180 net/unix/scm.c:66<br /> unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123<br /> unix_scm_to_skb net/unix/af_unix.c:1827 [inline]<br /> unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950<br /> unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]<br /> unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292<br /> sock_sendmsg_nosec net/socket.c:725 [inline]<br /> sock_sendmsg+0x148/0x160 net/socket.c:748<br /> ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494<br /> ___sys_sendmsg+0xc6/0x140 net/socket.c:2548<br /> __sys_sendmsg+0x94/0x140 net/socket.c:2577<br /> __do_sys_sendmsg net/socket.c:2586 [inline]<br /> __se_sys_sendmsg net/socket.c:2584 [inline]<br /> __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:<br /> too_many_unix_fds net/unix/scm.c:101 [inline]<br /> unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110<br /> unix_scm_to_skb net/unix/af_unix.c:1827 [inline]<br /> unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950<br /> unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]<br /> unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292<br /> sock_sendmsg_nosec net/socket.c:725 [inline]<br /> sock_sendmsg+0x148/0x160 net/socket.c:748<br /> ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494<br /> ___sys_sendmsg+0xc6/0x140 net/socket.c:2548<br /> __sys_sendmsg+0x94/0x140 net/socket.c:2577<br /> __do_sys_sendmsg net/socket.c:2586 [inline]<br /> __se_sys_sendmsg net/socket.c:2584 [inline]<br /> __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> value changed: 0x000000000000000c -&gt; 0x000000000000000d<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: rely on mt76_connac2_mac_tx_rate_val<br /> <br /> In order to fix a possible NULL pointer dereference in<br /> mt7996_mac_write_txwi() of vif pointer, export<br /> mt76_connac2_mac_tx_rate_val utility routine and reuse it<br /> in mt7996 driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: wraparound mbox producer index<br /> <br /> Driver is not handling the wraparound of the mbox producer index correctly.<br /> Currently the wraparound happens once u32 max is reached.<br /> <br /> Bit 31 of the producer index register is special and should be set<br /> only once for the first command. Because the producer index overflow<br /> setting bit31 after a long time, FW goes to initialization sequence<br /> and this causes FW hang.<br /> <br /> Fix is to wraparound the mbox producer index once it reaches u16 max.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: fix percpu counter block leak on error path when creating new netns<br /> <br /> Here is the stack where we allocate percpu counter block:<br /> <br /> +-

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails<br /> <br /> Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream().<br /> While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated<br /> skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we<br /> have an incorrect pkt_len or pkt_tag, the input skb is considered invalid<br /> and dropped. All the associated packets already in skb_pool should be<br /> dropped and freed. Added a comment describing this issue.<br /> <br /> The patch also makes remain_skb NULL after being processed so that it<br /> cannot be referenced after potential free. The initialization of hif_dev<br /> fields which are associated with remain_skb (rx_remain_len,<br /> rx_transfer_len and rx_pad_len) is moved after a new remain_skb is<br /> allocated.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: domains: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.