Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tt: fix TOCTOU race for reported vlans<br /> <br /> The local TT based TVLV is generated by first checking the number of VLANs<br /> which have at least one TT entry. A new buffer with the correct size for<br /> the VLANs is then allocated. Only then, the list of VLANs s used to fill<br /> the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock<br /> is held. But the actual number of TT entries of each VLAN can still<br /> increase during this time - just not the number of VLANs in the list.<br /> <br /> But the prefilter used in the buffer size calculation might still cause an<br /> increase of the number of VLANs which need to be stored. Simply because a<br /> VLAN might now suddenly have at least one entry when it had none in the<br /> pre-alloc check - and then needs to occupy space which was not allocated.<br /> <br /> It is better to overestimate the buffer size at the beginning and then fill<br /> the buffer only with the VLANs which are not empty.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap<br /> <br /> statmount_mnt_idmap() writes one mapping with seq_printf() and then<br /> manually advances seq-&gt;count to include the NUL separator.<br /> <br /> If seq_printf() overflows, seq_set_overflow() sets seq-&gt;count to<br /> seq-&gt;size. The manual seq-&gt;count++ changes this to seq-&gt;size + 1.<br /> seq_has_overflowed() then no longer detects the overflow. The corrupted<br /> count returns to statmount_string(), which later executes:<br /> <br /> seq-&gt;buf[seq-&gt;count++] = &amp;#39;\0&amp;#39;;<br /> <br /> This causes a 1-byte NULL out-of-bounds write on the dynamically<br /> allocated seq buffer.<br /> <br /> Fix this by checking for overflow immediately after seq_printf().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fprobe: Fix unregister_fprobe() to wait for RCU grace period<br /> <br /> Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")<br /> changed fprobe to register struct fprobe to an rcu-hlist, but it forgot<br /> to wait for RCU GP. Thus there can be use-after-free if the fprobe is<br /> released right after unregistering. This can be happened on fprobe<br /> event and sample module code.<br /> <br /> To fix this issue, add synchronize_rcu() in unregister_fprobe().<br /> <br /> Note that BPF is OK because fprobe is used as a part of<br /> bpf_kprobe_multi_link. This unregisters its fprobe in<br /> bpf_kprobe_multi_link_release() and it is deallocated via<br /> bpf_kprobe_multi_link_dealloc(), which is invoked from<br /> bpf_link_defer_dealloc_rcu_gp() RCU callback.<br /> <br /> For BPF, this also introduced unregister_fprobe_async() which does<br /> NOT wait for RCU grace priod.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: eb_tables: close module init race<br /> <br /> sashiko reports for unrelated patch:<br /> Does the core ebtables initialization in ebtables.c suffer from a similar race?<br /> Once nf_register_sockopt() completes, the sockopts are exposed globally.<br /> <br /> sockopt has to be registered last, just like in ip/ip6/arptables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: move to two-stage removal scheme<br /> <br /> Like previous patches for x_tables, follow same pattern in ebtables.<br /> We can&amp;#39;t reuse xt helpers: ebt_table struct layout is incompatible.<br /> <br /> table-&gt;ops assignment is now done while still holding the ebt mutex<br /> to make sure we never expose partially-filled table struct.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: add and use xtables_unregister_table_exit<br /> <br /> Previous change added xtables_unregister_table_pre_exit to detach the<br /> table from the packetpath and to unlink it from the active table list.<br /> In case of rmmod, userspace that is doing set/getsockopt for this table<br /> will not be able to re-instantiate the table:<br /> 1. The larval table has been removed already<br /> 2. existing instantiated table is no longer on the xt pernet table list.<br /> <br /> This adds the second stage helper:<br /> <br /> unlink the table from the dying list, free the hook ops (if any) and do<br /> the audit notification. It replaces xt_unregister_table().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: allocate hook ops while under mutex<br /> <br /> arp/ip(6)t_register_table() add the table to the per-netns list via<br /> xt_register_table() before allocating the per-netns hook ops copy<br /> via kmemdup_array(). This leaves a window where the table is<br /> visible in the list with ops=NULL.<br /> <br /> If the pernet exit happens runs concurrently the pre_exit callback finds<br /> the table via xt_find_table() and passes the NULL ops pointer to<br /> nf_unregister_net_hooks(), causing a NULL dereference:<br /> <br /> general protection fault in nf_unregister_net_hooks+0xbc/0x150<br /> RIP: nf_unregister_net_hooks (net/netfilter/core.c:613)<br /> Call Trace:<br /> ipt_unregister_table_pre_exit<br /> iptable_mangle_net_pre_exit<br /> ops_pre_exit_list<br /> cleanup_net<br /> <br /> Fix by moving the ops allocation into the xtables core so the table is<br /> never in the list without valid ops. Also ensure the table is no longer<br /> processing packets before its torn down on error unwind.<br /> nf_register_net_hooks might have published at least one hook; call<br /> synchronize_rcu() if there was an error.<br /> <br /> audit log register message gets deferred until all operations have<br /> passed, this avoids need to emit another ureg message in case of<br /> error unwinding.<br /> <br /> Based on earlier patch by Tristan Madani.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Snapshot notifier callbacks under lock<br /> <br /> Both notification handlers currently look up a notifier callback under<br /> notify_lock, drop the lock, and then dereference the returned<br /> notifier entry. A concurrent unregister can delete and free that<br /> entry in the gap, leaving the handler to dereference stale memory.<br /> <br /> Copy the callback pointer and callback data while notify_lock is<br /> still held and invoke the callback only after the lock is dropped.<br /> This keeps the existing callback execution model while removing the<br /> use-after-free window in both the framework and non-framework<br /> notification paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Validate framework notification message layout<br /> <br /> Framework notifications carry an indirect message in the shared RX<br /> buffer. Validate the reported offset and size before using them, reject<br /> zero-length payloads, and ensure that any non-header payload starts at<br /> the UUID field rather than in the middle of the message header.<br /> <br /> Use the validated offset and size values for both kmemdup() and the UUID<br /> parsing path so malformed firmware data cannot drive an out-of-bounds<br /> read or an oversized allocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix register corruption from uninitialized cregs on error<br /> <br /> compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when<br /> user_regset_copyin() fails. Since cregs is an uninitialized stack<br /> variable, a copyin failure causes uninitialized stack data to be written<br /> into the target task&amp;#39;s pt_regs, corrupting its register state and<br /> potentially leaking kernel stack contents.<br /> <br /> compat_restore_sigcontext() has the same issue: it calls cregs_to_regs()<br /> even when __copy_from_user() fails, leading to the same corruption of<br /> the signal-returning task&amp;#39;s register state on error.<br /> <br /> Only call cregs_to_regs() when the user copy succeeds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors<br /> <br /> adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the<br /> pin-status word as<br /> <br /> pins_status = read_buf[0] + (read_buf[1]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: fix VM_BUG_ON_FOLIO() issue in netfs_write_begin() call<br /> <br /> The multiple runs of generic/013 test-case is capable<br /> to reproduce a kernel BUG at mm/filemap.c:1504 with<br /> probability of 30%.<br /> <br /> while true; do<br /> sudo ./check generic/013<br /> done<br /> <br /> [ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322<br /> [ 9849.452412] memcg:ffff8881a1915800<br /> [ 9849.452417] aops:ceph_aops ino:1000058db9e dentry name(?):"f9XXXXXX"<br /> [ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)<br /> [ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248<br /> [ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800<br /> [ 9849.452447] page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))<br /> [ 9849.452474] ------------[ cut here ]------------<br /> [ 9849.452476] kernel BUG at mm/filemap.c:1504!<br /> [ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> [ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full)<br /> [ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1<br /> 0/2025<br /> [ 9849.484539] RIP: 0010:folio_unlock+0x85/0xa0<br /> [ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc<br /> cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84<br /> [ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246<br /> [ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000<br /> [ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000<br /> [ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000<br /> [ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000<br /> [ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000<br /> [ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0<br /> [ 9849.504459] PKRU: 55555554<br /> [ 9849.504626] Call Trace:<br /> [ 9849.505242] <br /> [ 9849.505379] netfs_write_begin+0x7c8/0x10a0<br /> [ 9849.505877] ? __kasan_check_read+0x11/0x20<br /> [ 9849.506384] ? __pfx_netfs_write_begin+0x10/0x10<br /> [ 9849.507178] ceph_write_begin+0x8c/0x1c0<br /> [ 9849.507934] generic_perform_write+0x391/0x8f0<br /> [ 9849.508503] ? __pfx_generic_perform_write+0x10/0x10<br /> [ 9849.509062] ? file_update_time_flags+0x19a/0x4b0<br /> [ 9849.509581] ? ceph_get_caps+0x63/0xf0<br /> [ 9849.510259] ? ceph_get_caps+0x63/0xf0<br /> [ 9849.510530] ceph_write_iter+0xe79/0x1ae0<br /> [ 9849.511282] ? __pfx_ceph_write_iter+0x10/0x10<br /> [ 9849.511839] ? lock_acquire+0x1ad/0x310<br /> [ 9849.512334] ? ksys_write+0xf9/0x230<br /> [ 9849.512582] ? lock_is_held_type+0xaa/0x140<br /> [ 9849.513128] vfs_write+0x512/0x1110<br /> [ 9849.513634] ? __fget_files+0x33/0x350<br /> [ 9849.513893] ? __pfx_vfs_write+0x10/0x10<br /> [ 9849.514143] ? mutex_lock_nested+0x1b/0x30<br /> [ 9849.514394] ksys_write+0xf9/0x230<br /> [ 9849.514621] ? __pfx_ksys_write+0x10/0x10<br /> [ 9849.514887] ? do_syscall_64+0x25e/0x1520<br /> [ 9849.515122] ? __kasan_check_read+0x11/0x20<br /> [ 9849.515366] ? trace_hardirqs_on_prepare+0x178/0x1c0<br /> [ 9849.515655] __x64_sys_write+0x72/0xd0<br /> [ 9849.515885] ? trace_hardirqs_on+0x24/0x1c0<br /> [ 9849.516130] x64_sys_call+0x22f/0x2390<br /> [ 9849.516341] do_syscall_64+0x12b/0x1520<br /> [ 9849.516545] ? do_syscall_64+0x27c/0x1520<br /> [ 9849.516783] ? do_syscall_64+0x27c/0x1520<br /> [ 9849.517003] ? lock_release+0x318/0x480<br /> [ 9849.517220] ? __x64_sys_io_getevents+0x143/0x2d0<br /> [ 9849.517479] ? percpu_ref_put_many.constprop.0+0x8f/0x210<br /> [ 9849.517779] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 9849.518073] ? do_syscall_64+0x25e/0x1520<br /> [ 9849.518291] ? __kasan_check_read+0x11/0x20<br /> [ 9849.518519] ? trace_hardirqs_on_prepare+0x178/0x1c0<br /> [ 9849.518799] ? do_syscall_64+0x27c/0x1520<br /> [ 9<br /> ---truncated---