Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix crash in nfsd4_read_release()<br /> <br /> When tracing is enabled, the trace_nfsd_read_done trace point<br /> crashes during the pynfs read.testNoFh test.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Define actions for the new time_deleg FATTR4 attributes<br /> <br /> NFSv4 clients won&amp;#39;t send legitimate GETATTR requests for these new<br /> attributes because they are intended to be used only with CB_GETATTR<br /> and SETATTR. But NFSD has to do something besides crashing if it<br /> ever sees a GETATTR request that queries these attributes.<br /> <br /> RFC 8881 Section 18.7.3 states:<br /> <br /> &gt; The server MUST return a value for each attribute that the client<br /> &gt; requests if the attribute is supported by the server for the<br /> &gt; target file system. If the server does not support a particular<br /> &gt; attribute on the target file system, then it MUST NOT return the<br /> &gt; attribute value and MUST NOT set the attribute bit in the result<br /> &gt; bitmap. The server MUST return an error if it supports an<br /> &gt; attribute on the target but cannot obtain its value. In that case,<br /> &gt; no attribute values will be returned.<br /> <br /> Further, RFC 9754 Section 5 states:<br /> <br /> &gt; These new attributes are invalid to be used with GETATTR, VERIFY,<br /> &gt; and NVERIFY, and they can only be used with CB_GETATTR and SETATTR<br /> &gt; by a client holding an appropriate delegation.<br /> <br /> Thus there does not appear to be a specific server response mandated<br /> by specification. Taking the guidance that querying these attributes<br /> via GETATTR is "invalid", NFSD will return nfserr_inval, failing the<br /> request entirely.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Fix epfile null pointer access after ep enable.<br /> <br /> A race condition occurs when ffs_func_eps_enable() runs concurrently<br /> with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()<br /> sets ffs-&gt;epfiles to NULL before resetting ffs-&gt;eps_count to 0, leading<br /> to a NULL pointer dereference when accessing epfile-&gt;ep in<br /> ffs_func_eps_enable() after successful usb_ep_enable().<br /> <br /> The ffs-&gt;epfiles pointer is set to NULL in both ffs_data_clear() and<br /> ffs_data_close() functions, and its modification is protected by the<br /> spinlock ffs-&gt;eps_lock. And the whole ffs_func_eps_enable() function<br /> is also protected by ffs-&gt;eps_lock.<br /> <br /> Thus, add NULL pointer handling for ffs-&gt;epfiles in the<br /> ffs_func_eps_enable() function to fix issues

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Fix device use-after-free on unbind<br /> <br /> A recent change fixed device reference leaks when looking up drm<br /> platform device driver data during bind() but failed to remove a partial<br /> fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix<br /> kobject put for component sub-drivers").<br /> <br /> This results in a reference imbalance on component bind() failures and<br /> on unbind() which could lead to a user-after-free.<br /> <br /> Make sure to only drop the references after retrieving the driver data<br /> by effectively reverting the previous partial fix.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: slimbus: fix bus_context pointer in regmap init calls<br /> <br /> Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in<br /> wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.<br /> That commit breaks audio playback, for instance, on sdm845 Thundercomm<br /> Dragonboard 845c board:<br /> <br /> Unable to handle kernel paging request at virtual address ffff8000847cbad4<br /> ...<br /> CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT<br /> Hardware name: Thundercomm Dragonboard 845c (DT)<br /> ...<br /> Call trace:<br /> slim_xfer_msg+0x24/0x1ac [slimbus] (P)<br /> slim_read+0x48/0x74 [slimbus]<br /> regmap_slimbus_read+0x18/0x24 [regmap_slimbus]<br /> _regmap_raw_read+0xe8/0x174<br /> _regmap_bus_read+0x44/0x80<br /> _regmap_read+0x60/0xd8<br /> _regmap_update_bits+0xf4/0x140<br /> _regmap_select_page+0xa8/0x124<br /> _regmap_raw_write_impl+0x3b8/0x65c<br /> _regmap_bus_raw_write+0x60/0x80<br /> _regmap_write+0x58/0xc0<br /> regmap_write+0x4c/0x80<br /> wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]<br /> snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]<br /> __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]<br /> dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]<br /> dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]<br /> snd_pcm_hw_params+0x124/0x464 [snd_pcm]<br /> snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]<br /> snd_pcm_ioctl+0x34/0x4c [snd_pcm]<br /> __arm64_sys_ioctl+0xac/0x104<br /> invoke_syscall+0x48/0x104<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xec<br /> el0t_64_sync_handler+0xa0/0xf0<br /> el0t_64_sync+0x198/0x19c<br /> <br /> The __devm_regmap_init_slimbus() started to be used instead of<br /> __regmap_init_slimbus() after the commit mentioned above and turns out<br /> the incorrect bus_context pointer (3rd argument) was used in<br /> __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal<br /> to &amp;slimbus-&gt;dev). Correct it. The wcd934x codec seems to be the only or<br /> the first user of devm_regmap_init_slimbus() but we should fix it till<br /> the point where __devm_regmap_init_slimbus() was introduced therefore<br /> two "Fixes" tags.<br /> <br /> While at this, also correct the same argument in __regmap_init_slimbus().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once<br /> <br /> hci_cmd_sync_dequeue_once() does lookup and then cancel<br /> the entry under two separate lock sections. Meanwhile,<br /> hci_cmd_sync_work() can also delete the same entry,<br /> leading to double list_del() and "UAF".<br /> <br /> Fix this by holding cmd_sync_work_lock across both<br /> lookup and cancel, so that the entry cannot be removed<br /> concurrently.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Sync pending IRQ work before freeing ring buffer<br /> <br /> Fix a race where irq_work can be queued in bpf_ringbuf_commit()<br /> but the ring buffer is freed before the work executes.<br /> In the syzbot reproducer, a BPF program attached to sched_switch<br /> triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer<br /> is freed before this work executes, the irq_work thread may accesses<br /> freed memory.<br /> Calling `irq_work_sync(&amp;rb-&gt;work)` ensures that all pending irq_work<br /> complete before freeing the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential cfid UAF in smb2_query_info_compound<br /> <br /> When smb2_query_info_compound() retries, a previously allocated cfid may<br /> have been freed in the first attempt.<br /> Because cfid wasn&amp;#39;t reset on replay, later cleanup could act on a stale<br /> pointer, leading to a potential use-after-free.<br /> <br /> Reinitialize cfid to NULL under the replay label.<br /> <br /> Example trace (trimmed):<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110<br /> [...]<br /> RIP: 0010:refcount_warn_saturate+0x9c/0x110<br /> [...]<br /> Call Trace:<br /> <br /> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> ? step_into+0x10d/0x690<br /> ? __legitimize_path+0x28/0x60<br /> smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> ? kmem_cache_alloc+0x18a/0x340<br /> ? getname_flags+0x46/0x1e0<br /> cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> statfs_by_dentry+0x67/0x90<br /> vfs_statfs+0x16/0xd0<br /> user_statfs+0x54/0xa0<br /> __do_sys_statfs+0x20/0x50<br /> do_syscall_64+0x58/0x80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode<br /> <br /> Currently, whenever there is a need to transmit an Action frame,<br /> the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to<br /> firmware. The P2P interfaces were available when wpa_supplicant is managing<br /> the wlan interface.<br /> <br /> However, the P2P interfaces are not created/initialized when only hostapd<br /> is managing the wlan interface. And if hostapd receives an ANQP Query REQ<br /> Action frame even from an un-associated STA, the brcmfmac driver tries<br /> to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.<br /> This NULL pointer dereferencing triggers a driver crash.<br /> <br /> [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000000<br /> [...]<br /> [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)<br /> [...]<br /> [ 1417.075653] Call trace:<br /> [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]<br /> [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]<br /> [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]<br /> [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211]<br /> [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158<br /> [ 1417.076302] genl_rcv_msg+0x220/0x2a0<br /> [ 1417.076317] netlink_rcv_skb+0x68/0x140<br /> [ 1417.076330] genl_rcv+0x40/0x60<br /> [ 1417.076343] netlink_unicast+0x330/0x3b8<br /> [ 1417.076357] netlink_sendmsg+0x19c/0x3f8<br /> [ 1417.076370] __sock_sendmsg+0x64/0xc0<br /> [ 1417.076391] ____sys_sendmsg+0x268/0x2a0<br /> [ 1417.076408] ___sys_sendmsg+0xb8/0x118<br /> [ 1417.076427] __sys_sendmsg+0x90/0xf8<br /> [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40<br /> [ 1417.076465] invoke_syscall+0x50/0x120<br /> [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0<br /> [ 1417.076506] do_el0_svc+0x24/0x38<br /> [ 1417.076525] el0_svc+0x30/0x100<br /> [ 1417.076548] el0t_64_sync_handler+0x100/0x130<br /> [ 1417.076569] el0t_64_sync+0x190/0x198<br /> [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)<br /> <br /> Fix this, by always using the vif corresponding to the wdev on which the<br /> Action frame Transmission request was initiated by the userspace. This way,<br /> even if P2P vif is not available, the IOVAR is sent to firmware on AP vif<br /> and the ANQP Query RESP Action frame is transmitted without crashing the<br /> driver.<br /> <br /> Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()<br /> to brcmf_p2p_attach(). Because the former function would not get executed<br /> when only hostapd is managing wlan interface, and it is not safe to do<br /> reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior<br /> init_completion().<br /> <br /> And in the brcmf_p2p_tx_action_frame() function, the condition check for<br /> P2P Presence response frame is not needed, since the wpa_supplicant is<br /> properly sending the P2P Presense Response frame on the P2P-GO vif instead<br /> of the P2P-Device vif.<br /> <br /> [Cc stable]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: bitblit: bound-check glyph index in bit_putcs*<br /> <br /> bit_putcs_aligned()/unaligned() derived the glyph pointer from the<br /> character value masked by 0xff/0x1ff, which may exceed the actual font&amp;#39;s<br /> glyph count and read past the end of the built-in font array.<br /> Clamp the index to the actual glyph count before computing the address.<br /> <br /> This fixes a global out-of-bounds read reported by syzbot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bcsp: receive data only if registered<br /> <br /> Currently, bcsp_recv() can be called even when the BCSP protocol has not<br /> been registered. This leads to a NULL pointer dereference, as shown in<br /> the following stack trace:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]<br /> RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590<br /> Call Trace:<br /> <br /> hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627<br /> tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290<br /> tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> To prevent this, ensure that the HCI_UART_REGISTERED flag is set before<br /> processing received data. If the protocol is not registered, return<br /> -EUNATCH.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: Fix UAF on sco_conn_free<br /> <br /> BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]<br /> BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]<br /> BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410<br /> net/bluetooth/sco.c:107<br /> Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352<br /> <br /> CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted<br /> 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: hci13 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x191/0x550 mm/kasan/report.c:482<br /> kasan_report+0xc4/0x100 mm/kasan/report.c:595<br /> sco_conn_free net/bluetooth/sco.c:87 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107<br /> sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]<br /> hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313<br /> hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121<br /> hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147<br /> hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689<br /> hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319<br /> worker_thread+0xbee/0x1200 kernel/workqueue.c:3400<br /> kthread+0x3c7/0x870 kernel/kthread.c:463<br /> ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 31370:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x70 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:388 [inline]<br /> __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4382 [inline]<br /> __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> sk_prot_alloc+0xae/0x220 net/core/sock.c:2239<br /> sk_alloc+0x34/0x5a0 net/core/sock.c:2295<br /> bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151<br /> sco_sock_alloc net/bluetooth/sco.c:562 [inline]<br /> sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593<br /> bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135<br /> __sock_create+0x3ad/0x780 net/socket.c:1589<br /> sock_create net/socket.c:1647 [inline]<br /> __sys_socket_create net/socket.c:1684 [inline]<br /> __sys_socket+0xd5/0x330 net/socket.c:1731<br /> __do_sys_socket net/socket.c:1745 [inline]<br /> __se_sys_socket net/socket.c:1743 [inline]<br /> __x64_sys_socket+0x7a/0x90 net/socket.c:1743<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 31374:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x70 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576<br /> poison_slab_object mm/kasan/common.c:243 [inline]<br /> __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2428 [inline]<br /> slab_free mm/slub.c:4701 [inline]<br /> kfree+0x199/0x3b0 mm/slub.c:4900<br /> sk_prot_free net/core/sock.c:2278 [inline]<br /> __sk_destruct+0x4aa/0x630 net/core/sock.c:2373<br /> sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333<br /> __sock_release net/socket.c:649 [inline]<br /> sock_close+0xb8/0x230 net/socket.c:1439<br /> __fput+0x3d1/0x9e0 fs/file_table.c:468<br /> task_work_run+0x206/0x2a0 kernel/task_work.c:227<br /> get_signal+0x1201/0x1410 kernel/signal.c:2807<br /> arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40<br /> exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]<br /> s<br /> ---truncated---