Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix deadlock in soft reset sequence<br /> <br /> The soft reset sequence is currently executed from the threaded IRQ<br /> handler, hence it cannot call disable_irq() which internally waits<br /> for IRQ handlers, i.e. itself, to complete.<br /> <br /> Use disable_irq_nosync() during a soft reset instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug<br /> <br /> When trying to do a rather aggressive test of igt&amp;#39;s "xe_module_load<br /> --r reload" with a full desktop environment and game running I noticed<br /> a few OOPSes when dereferencing freed pointers, related to<br /> framebuffers and property blobs after the compositor exits.<br /> <br /> Solve this by guarding the freeing in drm_file with drm_dev_enter/exit,<br /> and immediately put the references from struct drm_file objects during<br /> drm_dev_unplug().<br /> <br /> Related warnings for framebuffers on the subtest:<br /> [ 739.713076] ------------[ cut here ]------------<br /> WARN_ON(!list_empty(&amp;dev-&gt;mode_config.fb_list))<br /> [ 739.713079] WARNING: drivers/gpu/drm/drm_mode_config.c:584 at drm_mode_config_cleanup+0x30b/0x320 [drm], CPU#12: xe_module_load/13145<br /> ....<br /> [ 739.713328] Call Trace:<br /> [ 739.713330] <br /> [ 739.713335] ? intel_pmdemand_destroy_state+0x11/0x20 [xe]<br /> [ 739.713574] ? intel_atomic_global_obj_cleanup+0xe4/0x1a0 [xe]<br /> [ 739.713794] intel_display_driver_remove_noirq+0x51/0xb0 [xe]<br /> [ 739.714041] xe_display_fini_early+0x33/0x50 [xe]<br /> [ 739.714284] devm_action_release+0xf/0x20<br /> [ 739.714294] devres_release_all+0xad/0xf0<br /> [ 739.714301] device_unbind_cleanup+0x12/0xa0<br /> [ 739.714305] device_release_driver_internal+0x1b7/0x210<br /> [ 739.714311] device_driver_detach+0x14/0x20<br /> [ 739.714315] unbind_store+0xa6/0xb0<br /> [ 739.714319] drv_attr_store+0x21/0x30<br /> [ 739.714322] sysfs_kf_write+0x48/0x60<br /> [ 739.714328] kernfs_fop_write_iter+0x16b/0x240<br /> [ 739.714333] vfs_write+0x266/0x520<br /> [ 739.714341] ksys_write+0x72/0xe0<br /> [ 739.714345] __x64_sys_write+0x19/0x20<br /> [ 739.714347] x64_sys_call+0xa15/0xa30<br /> [ 739.714355] do_syscall_64+0xd8/0xab0<br /> [ 739.714361] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> and<br /> <br /> [ 739.714459] ------------[ cut here ]------------<br /> [ 739.714461] xe 0000:67:00.0: [drm] drm_WARN_ON(!list_empty(&amp;fb-&gt;filp_head))<br /> [ 739.714464] WARNING: drivers/gpu/drm/drm_framebuffer.c:833 at drm_framebuffer_free+0x6c/0x90 [drm], CPU#12: xe_module_load/13145<br /> [ 739.714715] RIP: 0010:drm_framebuffer_free+0x7a/0x90 [drm]<br /> ...<br /> [ 739.714869] Call Trace:<br /> [ 739.714871] <br /> [ 739.714876] drm_mode_config_cleanup+0x26a/0x320 [drm]<br /> [ 739.714998] ? __drm_printfn_seq_file+0x20/0x20 [drm]<br /> [ 739.715115] ? drm_mode_config_cleanup+0x207/0x320 [drm]<br /> [ 739.715235] intel_display_driver_remove_noirq+0x51/0xb0 [xe]<br /> [ 739.715576] xe_display_fini_early+0x33/0x50 [xe]<br /> [ 739.715821] devm_action_release+0xf/0x20<br /> [ 739.715828] devres_release_all+0xad/0xf0<br /> [ 739.715843] device_unbind_cleanup+0x12/0xa0<br /> [ 739.715850] device_release_driver_internal+0x1b7/0x210<br /> [ 739.715856] device_driver_detach+0x14/0x20<br /> [ 739.715860] unbind_store+0xa6/0xb0<br /> [ 739.715865] drv_attr_store+0x21/0x30<br /> [ 739.715868] sysfs_kf_write+0x48/0x60<br /> [ 739.715873] kernfs_fop_write_iter+0x16b/0x240<br /> [ 739.715878] vfs_write+0x266/0x520<br /> [ 739.715886] ksys_write+0x72/0xe0<br /> [ 739.715890] __x64_sys_write+0x19/0x20<br /> [ 739.715893] x64_sys_call+0xa15/0xa30<br /> [ 739.715900] do_syscall_64+0xd8/0xab0<br /> [ 739.715905] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> and then finally file close blows up:<br /> <br /> [ 743.186530] Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP<br /> [ 743.186535] CPU: 3 UID: 1000 PID: 3453 Comm: kwin_wayland Tainted: G W 7.0.0-rc1-valkyria+ #110 PREEMPT_{RT,(lazy)}<br /> [ 743.186537] Tainted: [W]=WARN<br /> [ 743.186538] Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3/X299 AORUS Gaming 3-CF, BIOS F8n 12/06/2021<br /> [ 743.186539] RIP: 0010:drm_framebuffer_cleanup+0x55/0xc0 [drm]<br /> [ 743.186588] Code: d8 72 73 0f b6 42 05 ff c3 39 c3 72 e8 49 8d bd 50 07 00 00 31 f6 e8 3a 80 d3 e1 49 8b 44 24 10 49 8d 7c 24 08 49 8b 54 24 08 3b 38 0f 85 95 7f 02 00 48 3b 7a 08 0f 85 8b 7f 02 00 48 89 42<br /> [ 743.186589] RSP: 0018:ffffc900085e3cf8 EFLAGS: 00<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN<br /> <br /> uart_write_room() and uart_write() behave inconsistently when<br /> xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were<br /> never properly initialized):<br /> <br /> - uart_write_room() returns kfifo_avail() which can be &gt; 0<br /> - uart_write() checks xmit_buf and returns 0 if NULL<br /> <br /> This inconsistency causes an infinite loop in drivers that rely on<br /> tty_write_room() to determine if they can write:<br /> <br /> while (tty_write_room(tty) &gt; 0) {<br /> written = tty-&gt;ops-&gt;write(...);<br /> // written is always 0, loop never exits<br /> }<br /> <br /> For example, caif_serial&amp;#39;s handle_tx() enters an infinite loop when<br /> used with PORT_UNKNOWN serial ports, causing system hangs.<br /> <br /> Fix by making uart_write_room() also check xmit_buf and return 0 if<br /> it&amp;#39;s NULL, consistent with uart_write().<br /> <br /> Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user<br /> <br /> After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in<br /> hci_chan_del"), l2cap_conn_del() uses conn-&gt;lock to protect access to<br /> conn-&gt;users. However, l2cap_register_user() and l2cap_unregister_user()<br /> don&amp;#39;t use conn-&gt;lock, creating a race condition where these functions can<br /> access conn-&gt;users and conn-&gt;hchan concurrently with l2cap_conn_del().<br /> <br /> This can lead to use-after-free and list corruption bugs, as reported<br /> by syzbot.<br /> <br /> Fix this by changing l2cap_register_user() and l2cap_unregister_user()<br /> to use conn-&gt;lock instead of hci_dev_lock(), ensuring consistent locking<br /> for the l2cap_conn structure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: HIDP: Fix possible UAF<br /> <br /> This fixes the following trace caused by not dropping l2cap_conn<br /> reference when user-&gt;remove callback is called:<br /> <br /> [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00<br /> [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy)<br /> [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> [ 97.809947] Call Trace:<br /> [ 97.809954] <br /> [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122)<br /> [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808)<br /> [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798)<br /> [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1))<br /> [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341)<br /> [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2))<br /> [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360)<br /> [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285)<br /> [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5))<br /> [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752)<br /> [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)<br /> [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691)<br /> [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678)<br /> [ 97.810404] __fput (fs/file_table.c:470)<br /> [ 97.810430] task_work_run (kernel/task_work.c:235)<br /> [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201)<br /> [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))<br /> [ 97.810527] do_exit (kernel/exit.c:972)<br /> [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897)<br /> [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6))<br /> [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4))<br /> [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1))<br /> [ 97.810721] do_group_exit (kernel/exit.c:1093)<br /> [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1))<br /> [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366)<br /> [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810826] ? vfs_read (fs/read_write.c:555)<br /> [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800)<br /> [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555)<br /> [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810960] arch_do_signal_or_restart (arch/<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: fsl: qbman: fix race condition in qman_destroy_fq<br /> <br /> When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there&amp;#39;s a race condition between<br /> fq_table[fq-&gt;idx] state and freeing/allocating from the pool and<br /> WARN_ON(fq_table[fq-&gt;idx]) in qman_create_fq() gets triggered.<br /> <br /> Indeed, we can have:<br /> Thread A Thread B<br /> qman_destroy_fq() qman_create_fq()<br /> qman_release_fqid()<br /> qman_shutdown_fq()<br /> gen_pool_free()<br /> -- At this point, the fqid is available again --<br /> qman_alloc_fqid()<br /> -- so, we can get the just-freed fqid in thread B --<br /> fq-&gt;fqid = fqid;<br /> fq-&gt;idx = fqid * 2;<br /> WARN_ON(fq_table[fq-&gt;idx]);<br /> fq_table[fq-&gt;idx] = fq;<br /> fq_table[fq-&gt;idx] = NULL;<br /> <br /> And adding some logs between qman_release_fqid() and<br /> fq_table[fq-&gt;idx] = NULL makes the WARN_ON() trigger a lot more.<br /> <br /> To prevent that, ensure that fq_table[fq-&gt;idx] is set to NULL before<br /> gen_pool_free() is called by using smp_wmb().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()<br /> <br /> In mpfs_sys_controller_probe(), if of_get_mtd_device_by_node() fails,<br /> the function returns immediately without freeing the allocated memory<br /> for sys_controller, leading to a memory leak.<br /> <br /> Fix this by jumping to the out_free label to ensure the memory is<br /> properly freed.<br /> <br /> Also, consolidate the error handling for the mbox_request_channel()<br /> failure case to use the same label.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: log new dentries when logging parent dir of a conflicting inode<br /> <br /> If we log the parent directory of a conflicting inode, we are not logging<br /> the new dentries of the directory, so when we finish we have the parent<br /> directory&amp;#39;s inode marked as logged but we did not log its new dentries.<br /> As a consequence if the parent directory is explicitly fsynced later and<br /> it does not have any new changes since we logged it, the fsync is a no-op<br /> and after a power failure the new dentries are missing.<br /> <br /> Example scenario:<br /> <br /> $ mkdir foo<br /> <br /> $ sync<br /> <br /> $rmdir foo<br /> <br /> $ mkdir dir1<br /> $ mkdir dir2<br /> <br /> # A file with the same name and parent as the directory we just deleted<br /> # and was persisted in a past transaction. So the deleted directory&amp;#39;s<br /> # inode is a conflicting inode of this new file&amp;#39;s inode.<br /> $ touch foo<br /> <br /> $ ln foo dir2/link<br /> <br /> # The fsync on dir2 will log the parent directory (".") because the<br /> # conflicting inode (deleted directory) does not exists anymore, but it<br /> # it does not log its new dentries (dir1).<br /> $ xfs_io -c "fsync" dir2<br /> <br /> # This fsync on the parent directory is no-op, since the previous fsync<br /> # logged it (but without logging its new dentries).<br /> $ xfs_io -c "fsync" .<br /> <br /> <br /> <br /> # After log replay dir1 is missing.<br /> <br /> Fix this by ensuring we log new dir dentries whenever we log the parent<br /> directory of a no longer existing conflicting inode.<br /> <br /> A test case for fstests will follow soon.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()<br /> <br /> In DecodeQ931(), the UserUserIE code path reads a 16-bit length from<br /> the packet, then decrements it by 1 to skip the protocol discriminator<br /> byte before passing it to DecodeH323_UserInformation(). If the encoded<br /> length is 0, the decrement wraps to -1, which is then passed as a<br /> large value to the decoder, leading to an out-of-bounds read.<br /> <br /> Add a check to ensure len is positive after the decrement.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case<br /> <br /> In decode_int(), the CONS case calls get_bits(bs, 2) to read a length<br /> value, then calls get_uint(bs, len) without checking that len bytes<br /> remain in the buffer. The existing boundary check only validates the<br /> 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()<br /> reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte<br /> slab-out-of-bounds read.<br /> <br /> Add a boundary check for len bytes after get_bits() and before<br /> get_uint().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()<br /> <br /> sip_help_tcp() parses the SIP Content-Length header with<br /> simple_strtoul(), which returns unsigned long, but stores the result in<br /> unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are<br /> silently truncated before computing the SIP message boundary.<br /> <br /> For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,<br /> causing the parser to miscalculate where the current message ends. The<br /> loop then treats trailing data in the TCP segment as a second SIP<br /> message and processes it through the SDP parser.<br /> <br /> Fix this by changing clen to unsigned long to match the return type of<br /> simple_strtoul(), and reject Content-Length values that exceed the<br /> remaining TCP payload length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()<br /> <br /> ctnetlink_dump_exp_ct() stores a conntrack pointer in cb-&gt;data for the<br /> netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the<br /> conntrack reference immediately after netlink_dump_start(). When the<br /> dump spans multiple rounds, the second recvmsg() triggers the dump<br /> callback which dereferences the now-freed conntrack via nfct_help(ct),<br /> leading to a use-after-free on ct-&gt;ext.<br /> <br /> The bug is that the netlink_dump_control has no .start or .done<br /> callbacks to manage the conntrack reference across dump rounds. Other<br /> dump functions in the same file (e.g. ctnetlink_get_conntrack) properly<br /> use .start/.done callbacks for this purpose.<br /> <br /> Fix this by adding .start and .done callbacks that hold and release the<br /> conntrack reference for the duration of the dump, and move the<br /> nfct_help() call after the cb-&gt;args[0] early-return check in the dump<br /> callback to avoid dereferencing ct-&gt;ext unnecessarily.<br /> <br /> BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0<br /> Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133<br /> <br /> CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY<br /> Call Trace:<br /> <br /> ctnetlink_exp_ct_dump_table+0x4f/0x2e0<br /> netlink_dump+0x333/0x880<br /> netlink_recvmsg+0x3e2/0x4b0<br /> ? aa_sk_perm+0x184/0x450<br /> sock_recvmsg+0xde/0xf0<br /> <br /> Allocated by task 133:<br /> kmem_cache_alloc_noprof+0x134/0x440<br /> __nf_conntrack_alloc+0xa8/0x2b0<br /> ctnetlink_create_conntrack+0xa1/0x900<br /> ctnetlink_new_conntrack+0x3cf/0x7d0<br /> nfnetlink_rcv_msg+0x48e/0x510<br /> netlink_rcv_skb+0xc9/0x1f0<br /> nfnetlink_rcv+0xdb/0x220<br /> netlink_unicast+0x3ec/0x590<br /> netlink_sendmsg+0x397/0x690<br /> __sys_sendmsg+0xf4/0x180<br /> <br /> Freed by task 0:<br /> slab_free_after_rcu_debug+0xad/0x1e0<br /> rcu_core+0x5c3/0x9c0