Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aspeed - fix double free caused by devm<br /> <br /> The clock obtained via devm_clk_get_enabled() is automatically managed<br /> by devres and will be disabled and freed on driver detach. Manually<br /> calling clk_disable_unprepare() in error path and remove function<br /> causes double free.<br /> <br /> Remove the manual clock cleanup in both aspeed_acry_probe()&amp;#39;s error<br /> path and aspeed_acry_remove().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix softlockup in ftrace_module_enable<br /> <br /> A soft lockup was observed when loading amdgpu module.<br /> If a module has a lot of tracable functions, multiple calls<br /> to kallsyms_lookup can spend too much time in RCU critical<br /> section and with disabled preemption, causing kernel panic.<br /> This is the same issue that was fixed in<br /> commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY<br /> kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to<br /> ftrace_graph_set_hash()").<br /> <br /> Fix it the same way by adding cond_resched() in ftrace_module_enable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amd/amdkfd: enhance kfd process check in switch partition<br /> <br /> current switch partition only check if kfd_processes_table is empty.<br /> kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but<br /> kfd_process tear down is in kfd_process_wq_release.<br /> <br /> consider two processes:<br /> <br /> Process A (workqueue) -&gt; kfd_process_wq_release -&gt; Access kfd_node member<br /> Process B switch partition -&gt; amdgpu_xcp_pre_partition_switch -&gt; amdgpu_amdkfd_device_fini_sw<br /> -&gt; kfd_node tear down.<br /> <br /> Process A and B may trigger a race as shown in dmesg log.<br /> <br /> This patch is to resolve the race by adding an atomic kfd_process counter<br /> kfd_processes_count, it increment as create kfd process, decrement as<br /> finish kfd_process_wq_release.<br /> <br /> v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds<br /> and bug fix. (Philip Yang)<br /> <br /> [3966658.307702] divide error: 0000 [#1] SMP NOPTI<br /> [3966658.350818] i10nm_edac<br /> [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted<br /> [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]<br /> [3966658.362839] nfit<br /> [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]<br /> [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00<br /> [3966658.380967] x86_pkg_temp_thermal<br /> [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246<br /> [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000<br /> [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00<br /> [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4<br /> [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000<br /> [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800<br /> [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000<br /> [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0<br /> [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [3966658.391536] PKRU: 55555554<br /> [3966658.391536] Call Trace:<br /> [3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu]<br /> [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu]<br /> [3966658.399754] intel_powerclamp<br /> [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]<br /> [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu]<br /> [3966658.410516] coretemp<br /> [3966658.434016] process_one_work+0x1ad/0x380<br /> [3966658.434021] worker_thread+0x49/0x310<br /> [3966658.438963] kvm_intel<br /> [3966658.446041] ? process_one_work+0x380/0x380<br /> [3966658.446045] kthread+0x118/0x140<br /> [3966658.446047] ? __kthread_bind_mask+0x60/0x60<br /> [3966658.446050] ret_from_fork+0x1f/0x30<br /> [3966658.446053] Modules linked in: kpatch_20765354(OEK)<br /> [3966658.455310] kvm<br /> [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)<br /> [3966658.473462] idxd_mdev<br /> [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock<br /> <br /> The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix multifs mds auth caps issue<br /> <br /> The mds auth caps check should also validate the<br /> fsname along with the associated caps. Not doing<br /> so would result in applying the mds auth caps of<br /> one fs on to the other fs in a multifs ceph cluster.<br /> The bug causes multiple issues w.r.t user<br /> authentication, following is one such example.<br /> <br /> Steps to Reproduce (on vstart cluster):<br /> 1. Create two file systems in a cluster, say &amp;#39;fsname1&amp;#39; and &amp;#39;fsname2&amp;#39;<br /> 2. Authorize read only permission to the user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname1&amp;#39;<br /> $ceph fs authorize fsname1 client.usr / r<br /> 3. Authorize read and write permission to the same user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname2&amp;#39;<br /> $ceph fs authorize fsname2 client.usr / rw<br /> 4. Update the keyring<br /> $ceph auth get client.usr &gt;&gt; ./keyring<br /> <br /> With above permssions for the user &amp;#39;client.usr&amp;#39;, following is the<br /> expectation.<br /> a. The &amp;#39;client.usr&amp;#39; should be able to only read the contents<br /> and not allowed to create or delete files on file system &amp;#39;fsname1&amp;#39;.<br /> b. The &amp;#39;client.usr&amp;#39; should be able to read/write on file system &amp;#39;fsname2&amp;#39;.<br /> <br /> But, with this bug, the &amp;#39;client.usr&amp;#39; is allowed to read/write on file<br /> system &amp;#39;fsname1&amp;#39;. See below.<br /> <br /> 5. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.usr&amp;#39;<br /> $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/<br /> 6. Try creating a file on file system &amp;#39;fsname1&amp;#39; with user &amp;#39;client.usr&amp;#39;. This<br /> should fail but passes with this bug.<br /> $touch /kmnt_fsname1_usr/file1<br /> 7. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.admin&amp;#39; and create a<br /> file.<br /> $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin<br /> $echo "data" &gt; /kmnt_fsname1_admin/admin_file1<br /> 8. Try removing an existing file on file system &amp;#39;fsname1&amp;#39; with the user<br /> &amp;#39;client.usr&amp;#39;. This shoudn&amp;#39;t succeed but succeeds with the bug.<br /> $rm -f /kmnt_fsname1_usr/admin_file1<br /> <br /> For more information, please take a look at the corresponding mds/fuse patch<br /> and tests added by looking into the tracker mentioned below.<br /> <br /> v2: Fix a possible null dereference in doutc<br /> v3: Don&amp;#39;t store fsname from mdsmap, validate against<br /> ceph_mount_options&amp;#39;s fsname and use it<br /> v4: Code refactor, better warning message and<br /> fix possible compiler warning<br /> <br /> [ Slava.Dubeyko: "fsname check failed" -&gt; "fsname mismatch" ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: fix field-spanning memcpy warning in AH output<br /> <br /> Fix field-spanning memcpy warnings in ah6_output() and<br /> ah6_output_done() where extension headers are copied to/from IPv6<br /> address fields, triggering fortify-string warnings about writes beyond<br /> the 16-byte address fields.<br /> <br /> memcpy: detected field-spanning write (size 40) of single field "&amp;top_iph-&gt;saddr" at net/ipv6/ah6.c:439 (size 16)<br /> WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439<br /> <br /> The warnings are false positives as the extension headers are<br /> intentionally placed after the IPv6 header in memory. Fix by properly<br /> copying addresses and extension headers separately, and introduce<br /> helper functions to avoid code duplication.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: fix invalid pointer access in debugfs<br /> <br /> If the memory allocation in gpiolib_seq_start() fails, the s-&gt;private<br /> field remains uninitialized and is later dereferenced without checking<br /> in gpiolib_seq_stop(). Initialize s-&gt;private to NULL before calling<br /> kzalloc() and check it before dereferencing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix uninitialized waitqueue in transaction manager<br /> <br /> The transaction manager initialization in txInit() was not properly<br /> initializing TxBlock[0].waitor waitqueue, causing a crash when<br /> txEnd(0) is called on read-only filesystems.<br /> <br /> When a filesystem is mounted read-only, txBegin() returns tid=0 to<br /> indicate no transaction. However, txEnd(0) still gets called and<br /> tries to access TxBlock[0].waitor via tid_to_tblock(0), but this<br /> waitqueue was never initialized because the initialization loop<br /> started at index 1 instead of 0.<br /> <br /> This causes a &amp;#39;non-static key&amp;#39; lockdep warning and system crash:<br /> INFO: trying to register non-static key in txEnd<br /> <br /> Fix by ensuring all transaction blocks including TxBlock[0] have<br /> their waitqueues properly initialized during txInit().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netpoll: Fix deadlock in memory allocation under spinlock<br /> <br /> Fix a AA deadlock in refill_skbs() where memory allocation while holding<br /> skb_pool-&gt;lock can trigger a recursive lock acquisition attempt.<br /> <br /> The deadlock scenario occurs when the system is under severe memory<br /> pressure:<br /> <br /> 1. refill_skbs() acquires skb_pool-&gt;lock (spinlock)<br /> 2. alloc_skb() is called while holding the lock<br /> 3. Memory allocator fails and calls slab_out_of_memory()<br /> 4. This triggers printk() for the OOM warning<br /> 5. The console output path calls netpoll_send_udp()<br /> 6. netpoll_send_udp() attempts to acquire the same skb_pool-&gt;lock<br /> 7. Deadlock: the lock is already held by the same CPU<br /> <br /> Call stack:<br /> refill_skbs()<br /> spin_lock_irqsave(&amp;skb_pool-&gt;lock) lock)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Do not kfree() devres managed rdev<br /> <br /> Since the allocation of the drivers main structure was changed to<br /> devm_drm_dev_alloc() rdev is managed by devres and we shouldn&amp;#39;t be calling<br /> kfree() on it.<br /> <br /> This fixes things exploding if the driver probe fails and devres cleans up<br /> the rdev after we already free&amp;#39;d it.<br /> <br /> (cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Ensure XFD state on signal delivery<br /> <br /> Sean reported [1] the following splat when running KVM tests:<br /> <br /> WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70<br /> Call Trace:<br /> <br /> fpu__clear_user_states+0x9c/0x100<br /> arch_do_signal_or_restart+0x142/0x210<br /> exit_to_user_mode_loop+0x55/0x100<br /> do_syscall_64+0x205/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Chao further identified [2] a reproducible scenario involving signal<br /> delivery: a non-AMX task is preempted by an AMX-enabled task which<br /> modifies the XFD MSR.<br /> <br /> When the non-AMX task resumes and reloads XSTATE with init values,<br /> a warning is triggered due to a mismatch between fpstate::xfd and the<br /> CPU&amp;#39;s current XFD state. fpu__clear_user_states() does not currently<br /> re-synchronize the XFD state after such preemption.<br /> <br /> Invoke xfd_update_state() which detects and corrects the mismatch if<br /> there is a dynamic feature.<br /> <br /> This also benefits the sigreturn path, as fpu__restore_sig() may call<br /> fpu__clear_user_states() when the sigframe is inaccessible.<br /> <br /> [ dhansen: minor changelog munging ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/mellanox: mlxbf-pmc: add sysfs_attr_init() to count_clock init<br /> <br /> The lock-related debug logic (CONFIG_LOCK_STAT) in the kernel is noting<br /> the following warning when the BlueField-3 SOC is booted:<br /> <br /> BUG: key ffff00008a3402a8 has not been registered!<br /> ------------[ cut here ]------------<br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 4 PID: 592 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x1d4/0x2a0<br /> <br /> Call trace:<br /> lockdep_init_map_type+0x1d4/0x2a0<br /> __kernfs_create_file+0x84/0x140<br /> sysfs_add_file_mode_ns+0xcc/0x1cc<br /> internal_create_group+0x110/0x3d4<br /> internal_create_groups.part.0+0x54/0xcc<br /> sysfs_create_groups+0x24/0x40<br /> device_add+0x6e8/0x93c<br /> device_register+0x28/0x40<br /> __hwmon_device_register+0x4b0/0x8a0<br /> devm_hwmon_device_register_with_groups+0x7c/0xe0<br /> mlxbf_pmc_probe+0x1e8/0x3e0 [mlxbf_pmc]<br /> platform_probe+0x70/0x110<br /> <br /> The mlxbf_pmc driver must call sysfs_attr_init() during the<br /> initialization of the "count_clock" data structure to avoid<br /> this warning.