In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid use-after-free in ip6_fragment()Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.It seems to not be always true, at least for UDP stack.syzbot reported:BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace:__dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106print_address_description mm/kasan/report.c:284 [inline]print_report+0x15e/0x45d mm/kasan/report.c:395kasan_report+0xbf/0x1f0 mm/kasan/report.c:495ip6_dst_idev include/net/ip6_fib.h:245 [inline]ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951__ip6_finish_output net/ipv6/ip6_output.c:193 [inline]ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227dst_output include/net/dst.h:445 [inline]ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg+0xd3/0x120 net/socket.c:734sock_write_iter+0x295/0x3d0 net/socket.c:1108call_write_iter include/linux/fs.h:2191 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x9ed/0xdd0 fs/read_write.c:584ksys_write+0x1ec/0x250 fs/read_write.c:637do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fde3588c0d9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000aRBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000Allocated by task 7618:kasan_save_stack+0x22/0x40 mm/kasan/common.c:45kasan_set_track+0x25/0x30 mm/kasan/common.c:52__kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325kasan_slab_alloc include/linux/kasan.h:201 [inline]slab_post_alloc_hook mm/slab.h:737 [inline]slab_alloc_node mm/slub.c:3398 [inline]slab_alloc mm/slub.c:3406 [inline]__kmem_cache_alloc_lru mm/slub.c:3413 [inline]kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422dst_alloc+0x14a/0x1f0 net/core/dst.c:92ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254pol_lookup_func include/net/ip6_fib.h:582 [inline]fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638ip6_route_output include/net/ip6_route.h:98 [inline]ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665sock_sendmsg_nosec n---truncated---

In the Linux kernel, the following vulnerability has been resolved:net: thunderbolt: fix memory leak in tbnet_open()When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated intb_xdomain_alloc_out_hopid() is not released. Addtb_xdomain_release_out_hopid() to the error path to release ida.

In the Linux kernel, the following vulnerability has been resolved:rtc: cmos: Fix event handler registration ordering issueBecause acpi_install_fixed_event_handler() enables the eventautomatically on success, it is incorrect to call it before thehandler routine passed to it is ready to handle events.Unfortunately, the rtc-cmos driver does exactly the incorrect thingby calling cmos_wake_setup(), which passes rtc_handler() toacpi_install_fixed_event_handler(), before cmos_do_probe(), becausertc_handler() uses dev_get_drvdata() to get to the cmos objectpointer and the driver data pointer is only populated incmos_do_probe().This leads to a NULL pointer dereference in rtc_handler() on bootif the RTC fixed event happens to be active at the init time.To address this issue, change the initialization ordering of thedriver so that cmos_wake_setup() is always called after a successfulcmos_do_probe() call.While at it, change cmos_pnp_probe() to call cmos_do_probe() afterthe initial if () statement used for computing the IRQ argument tobe passed to cmos_do_probe() which is cleaner than calling it ineach branch of that if () (local variable "irq" can be of type int,because it is passed to that function as an argument of type int).Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not checkACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger numberof systems, because previously it only affected systems withACPI_FADT_LOW_POWER_S0 set, but it is present regardless of thatcommit.

In the Linux kernel, the following vulnerability has been resolved:perf: Fix perf_pending_task() UaFPer syzbot it is possible for perf_pending_task() to run after theevent is free()'d. There are two related but distinct cases:- the task_work was already queued before destroying the event;- destroying the event itself queues the task_work.The first cannot be solved using task_work_cancel() sinceperf_release() itself might be called from a task_work (____fput),which means the current->task_works list is already empty andtask_work_cancel() won't be able to find the perf_pending_task()entry.The simplest alternative is extending the perf_event lifetime to coverthe task_work.The second is just silly, queueing a task_work while you know theevent is going away makes no sense and is easily avoided byre-arranging how the event is marked STATE_DEAD and ensuring it goesthrough STATE_OFF on the way down.

In some cases search terms persisted in the URL bar even after navigating away from the search page. This vulnerability affects Firefox < 141, Firefox ESR < 140.1, Thunderbird < 141, and Thunderbird < 140.1.

Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim’s internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.

Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1400, When processing nested tuples in Vim script, an error during evaluation can trigger a use-after-free in Vim’s internal tuple reference management. Specifically, the tuple_unref() function may access already freed memory due to improper lifetime handling, leading to memory corruption. The exploit requires direct user interaction, as the script must be explicitly executed within Vim. This issue has been patched in version 9.1.1400.

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.2 through 3.3.0, there is a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. This is fixed in version 3.3.3.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nefivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths\nWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)\nearly in fs_context initialization. However, sfi is associated with the\nsuperblock and typically freed when the superblock is destroyed. If the\nfs_context is released (final put) before fill_super is called—such as\non error paths or during reconfiguration—the sfi structure would leak,\nas ownership never transfers to the superblock.\nImplement the .free callback in efivarfs_context_ops to ensure any\nallocated sfi is properly freed if the fs_context is torn down before\nfill_super, preventing this memory leak.

In the Linux kernel, the following vulnerability has been resolved:\niio: adc: axp20x_adc: Add missing sentinel to AXP717 ADC channel maps\nThe AXP717 ADC channel maps is missing a sentinel entry at the end. This\ncauses a KASAN warning.\nAdd the missing sentinel entry.

In the Linux kernel, the following vulnerability has been resolved:\nnet: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_info\nWhile transitioning from netdev_alloc_ip_align() to build_skb(), memory\nfor the "skb_shared_info" member of an "skb" was not allocated. Fix this\nby allocating "PAGE_SIZE" as the skb length, accounting for the packet\nlength, headroom and tailroom, thereby including the required memory space\nfor skb_shared_info.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init()\ndevm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init()\ndoes not check for this case, which results in a NULL pointer\ndereference.\nAdd NULL check after devm_kasprintf() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:\nnet: airoha: fix potential use-after-free in airoha_npu_get()\nnp->name was being used after calling of_node_put(np), which\nreleases the node and can lead to a use-after-free bug.\nPreviously, of_node_put(np) was called unconditionally after\nof_find_device_by_node(np), which could result in a use-after-free if\npdev is NULL.\nThis patch moves of_node_put(np) after the error check to ensure\nthe node is only released after both the error and success cases\nare handled appropriately, preventing potential resource issues.

In the Linux kernel, the following vulnerability has been resolved:\nnetfs: Fix copy-to-cache so that it performs collection with ceph+fscache\nThe netfs copy-to-cache that is used by Ceph with local caching sets up a\nnew request to write data just read to the cache. The request is started\nand then left to look after itself whilst the app continues. The request\ngets notified by the backing fs upon completion of the async DIO write, but\nthen tries to wake up the app because NETFS_RREQ_OFFLOAD_COLLECTION isn't\nset - but the app isn't waiting there, and so the request just hangs.\nFix this by setting NETFS_RREQ_OFFLOAD_COLLECTION which causes the\nnotification from the backing filesystem to put the collection onto a work\nqueue instead.

In the Linux kernel, the following vulnerability has been resolved:\nrxrpc: Fix irq-disabled in local_bh_enable()\nThe rxrpc_assess_MTU_size() function calls down into the IP layer to find\nout the MTU size for a route. When accepting an incoming call, this is\ncalled from rxrpc_new_incoming_call() which holds interrupts disabled\nacross the code that calls down to it. Unfortunately, the IP layer uses\nlocal_bh_enable() which, config dependent, throws a warning if IRQs are\nenabled:\nWARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0\n...\nRIP: 0010:__local_bh_enable_ip+0x43/0xd0\n...\nCall Trace:\n\nrt_cache_route+0x7e/0xa0\nrt_set_nexthop.isra.0+0x3b3/0x3f0\n__mkroute_output+0x43a/0x460\nip_route_output_key_hash+0xf7/0x140\nip_route_output_flow+0x1b/0x90\nrxrpc_assess_MTU_size.isra.0+0x2a0/0x590\nrxrpc_new_incoming_peer+0x46/0x120\nrxrpc_alloc_incoming_call+0x1b1/0x400\nrxrpc_new_incoming_call+0x1da/0x5e0\nrxrpc_input_packet+0x827/0x900\nrxrpc_io_thread+0x403/0xb60\nkthread+0x2f7/0x310\nret_from_fork+0x2a/0x230\nret_from_fork_asm+0x1a/0x30\n...\nhardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50\nhardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70\nsoftirqs last enabled at (0): copy_process+0xc61/0x2730\nsoftirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90\nFix this by moving the call to rxrpc_assess_MTU_size() out of\nrxrpc_init_peer() and further up the stack where it can be done without\ninterrupts disabled.\nIt shouldn't be a problem for rxrpc_new_incoming_call() to do it after the\nlocks are dropped as pmtud is going to be performed by the I/O thread - and\nwe're in the I/O thread at this point.

In the Linux kernel, the following vulnerability has been resolved:\nrxrpc: Fix recv-recv race of completed call\nIf a call receives an event (such as incoming data), the call gets placed\non the socket's queue and a thread in recvmsg can be awakened to go and\nprocess it. Once the thread has picked up the call off of the queue,\nfurther events will cause it to be requeued, and once the socket lock is\ndropped (recvmsg uses call->user_mutex to allow the socket to be used in\nparallel), a second thread can come in and its recvmsg can pop the call off\nthe socket queue again.\nIn such a case, the first thread will be receiving stuff from the call and\nthe second thread will be blocked on call->user_mutex. The first thread\ncan, at this point, process both the event that it picked call for and the\nevent that the second thread picked the call for and may see the call\nterminate - in which case the call will be "released", decoupling the call\nfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the control\nmessage).\nThe first thread will return okay, but then the second thread will wake up\nholding the user_mutex and, if it sees that the call has been released by\nthe first thread, it will BUG thusly:\nkernel BUG at net/rxrpc/recvmsg.c:474!\nFix this by just dequeuing the call and ignoring it if it is seen to be\nalready released. We can't tell userspace about it anyway as the user call\nID has become stale.

In the Linux kernel, the following vulnerability has been resolved:\ncifs: Fix the smbd_response slab to allow usercopy\nThe handling of received data in the smbdirect client code involves using\ncopy_to_iter() to copy data from the smbd_reponse struct's packet trailer\nto a folioq buffer provided by netfslib that encapsulates a chunk of\npagecache.\nIf, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks\nthen performed in copy_to_iter() oopsing with something like the following:\nCIFS: Attempting to mount //172.31.9.1/test\nCIFS: VFS: RDMA transport established\nusercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!\n------------[ cut here ]------------\nkernel BUG at mm/usercopy.c:102!\n...\nRIP: 0010:usercopy_abort+0x6c/0x80\n...\nCall Trace:\n\n__check_heap_object+0xe3/0x120\n__check_object_size+0x4dc/0x6d0\nsmbd_recv+0x77f/0xfe0 [cifs]\ncifs_readv_from_socket+0x276/0x8f0 [cifs]\ncifs_read_from_socket+0xcd/0x120 [cifs]\ncifs_demultiplex_thread+0x7e9/0x2d50 [cifs]\nkthread+0x396/0x830\nret_from_fork+0x2b8/0x3b0\nret_from_fork_asm+0x1a/0x30\nThe problem is that the smbd_response slab's packet field isn't marked as\nbeing permitted for usercopy.\nFix this by passing parameters to kmem_slab_create() to indicate that\ncopy_to_iter() is permitted from the packet region of the smbd_response\nslab objects, less the header space.

In the Linux kernel, the following vulnerability has been resolved:\nsched/ext: Prevent update_locked_rq() calls with NULL rq\nAvoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL\nin the SCX_CALL_OP and SCX_CALL_OP_RET macros.\nPreviously, calling update_locked_rq(NULL) with preemption enabled could\ntrigger the following warning:\nBUG: using __this_cpu_write() in preemptible [00000000]\nThis happens because __this_cpu_write() is unsafe to use in preemptible\ncontext.\nrq is NULL when an ops invoked from an unlocked context. In such cases, we\ndon't need to store any rq, since the value should already be NULL\n(unlocked). Ensure that update_locked_rq() is only called when rq is\nnon-NULL, preventing calling __this_cpu_write() on preemptible context.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: reject VHT opmode for unsupported channel widths\n\nVHT operating mode notifications are not defined for channel widths\nbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under the\nVHT specification and must be rejected.\n\nWithout this check, malformed notifications using these widths may\nreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due to\ninvalid input. This issue was reported by syzbot.\n\nReject these unsupported widths early in sta_link_apply_parameters()\nwhen opmode_notif is used. The accepted set includes 20, 40, 80, 160,\nand 80+80 MHz, which are valid for VHT. While 320 MHz is not defined\nfor VHT, it is allowed to avoid rejecting HE or EHT clients that may\nstill send a VHT opmode notification.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Allow CPU to reschedule while setting per-page memory attributes\n\nWhen running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),\nthe host can experience CPU soft lockups when running an operation in\nkvm_vm_set_mem_attributes() to set memory attributes on the whole\nrange of guest memory.\n\nwatchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]\nCPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)\nHardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024\nRIP: 0010:xas_create+0x78/0x1f0\nCode: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87\nRSP: 0018:ffffad890a34b940 EFLAGS: 00000286\nRAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000\nRDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868\nR13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868\nFS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \n xas_store+0x58/0x630\n __xa_store+0xa5/0x130\n xa_store+0x2c/0x50\n kvm_vm_set_mem_attributes+0x343/0x710 [kvm]\n kvm_vm_ioctl+0x796/0xab0 [kvm]\n __x64_sys_ioctl+0xa3/0xd0\n do_syscall_64+0x8c/0x7a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f5578d031bb\nCode: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb\nRDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b\nRBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000\nR10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120\nR13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0\n\nWhile looping through the range of memory setting the attributes,\ncall cond_resched() to give the scheduler a chance to run a higher\npriority task on the runqueue if necessary and avoid staying in\nkernel mode long enough to trigger the lockup.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/zcrx: fix pp destruction warnings\n\nWith multiple page pools and in some other cases we can have allocated\nniovs on page pool destruction. Remove a misplaced warning checking that\nall niovs are returned to zcrx on io_pp_zc_destroy(). It was reported\nbefore but apparently got lost.

In the Linux kernel, the following vulnerability has been resolved:\nksmbd: validate command request size\nIn commit 2b9b8f3b68ed ("ksmbd: validate command payload size"), except\nfor SMB2_OPLOCK_BREAK_HE command, the request size of other commands\nis not checked, it's not expected. Fix it by add check for request\nsize of other commands.

A flaw was found in cmd/go. The `go` command can execute arbitrary commands when processing untrusted version control system (VCS) repositories containing malicious configuration. This issue occurs because the command interprets VCS metadata, potentially leading to unintended command execution. This vulnerability allows a malicious actor to trigger this by providing a repository with a crafted VCS configuration, resulting in arbitrary code execution within the context of the `go` process.

Improper neutralization of newlines in pg_dump in PostgreSQL allows a user of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands inside a purpose-crafted object name. The same attacks can achieve SQL injection as a superuser of the restore target server. pg_dumpall, pg_restore, and pg_upgrade are also affected. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected. Versions before 11.20 are unaffected. CVE-2012-0868 had fixed this class of problem, but version 11.20 reintroduced it.

No description is available for this CVE.

A mismatch caused by client-triggered server-sent stream resets between HTTP/2 specifications and the internal architectures of some HTTP/2 implementations may result in excessive server resource consumption leading to denial-of-service (DoS). By opening streams and then rapidly triggering the server to reset them—using malformed frames or flow control errors—an attacker can exploit incorrect stream accounting. Streams reset by the server are considered closed at the protocol level, even though backend processing continues. This allows a client to cause the server to handle an unbounded number of concurrent streams on a single connection. This CVE will be updated as affected product details are released.

A flaw was found in Apache Tomcat where malformed client requests can trigger server-side stream resets without triggering abuse counters. This issue, referred to as the "MadeYouReset" attack, allows malicious clients to induce excessive server workload by repeatedly causing server-side stream aborts. While not a protocol bug, this highlights a common implementation weakness that can be exploited to cause a denial of service (DoS).

Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error.

No description is available for this CVE.

LuaJIT through 2.1 and OpenRusty luajit2 before v2.1-20240314 have an unsinking of IR_FSTORE for NULL metatable, which leads to Denial of Service (DoS).

No description is available for this CVE.

No description is available for this CVE.

There exists a stack buffer overflow in libjxl. A specifically-crafted file can cause the JPEG XL decoder to use large amounts of stack space (up to 256mb is possible, maybe 512mb), potentially exhausting the stack. An attacker can craft a file that will cause excessive memory usage. We recommend upgrading past commit 65fbec56bc578b6b6ee02a527be70787bbd053b0.

Go before 1.10.8 and 1.11.x before 1.11.5 mishandles P-521 and P-384 elliptic curves, which allows attackers to cause a denial of service (CPU consumption) or possibly conduct ECDH private key recovery attacks.

Focus incorrectly truncated URLs towards the beginning instead of around the origin. This vulnerability affects Firefox < 141 and Thunderbird < 141.

Memory safety bugs present in Firefox ESR 140.0, Thunderbird ESR 140.0, Firefox 140 and Thunderbird 140. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 141, Firefox ESR < 140.1, Thunderbird < 141, and Thunderbird < 140.1.

Thunderbird ignored paths when checking the validity of navigations in a frame. This vulnerability affects Firefox < 141, Firefox ESR < 140.1, Thunderbird < 141, and Thunderbird < 140.1.

Insufficient validation of untrusted input in ANGLE and GPU in Google Chrome prior to 138.0.7204.157 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

An issue in the pdfseparate utility of freedesktop poppler v25.04.0 allows attackers to cause an infinite recursion via supplying a crafted PDF file. This can lead to a Denial of Service (DoS).

A use-after-free issue was addressed with improved memory management. This issue is fixed in Safari 18.6, watchOS 11.6, iOS 18.6 and iPadOS 18.6, iPadOS 17.7.9, tvOS 18.6, macOS Sequoia 15.6, visionOS 2.6. Processing maliciously crafted web content may lead to an unexpected Safari crash.

The issue was addressed with improved memory handling. This issue is fixed in Safari 18.6, macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, watchOS 11.6, visionOS 2.6. Processing maliciously crafted web content may lead to an unexpected Safari crash.

The issue was addressed with improved memory handling. This issue is fixed in Safari 18.6, iPadOS 17.7.9, watchOS 11.6, visionOS 2.6, iOS 18.6 and iPadOS 18.6, macOS Sequoia 15.6, tvOS 18.6. Processing maliciously crafted web content may lead to memory corruption.

The issue was addressed with improved memory handling. This issue is fixed in Safari 18.6, macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, watchOS 11.6, visionOS 2.6. Processing maliciously crafted web content may lead to memory corruption.

The issue was addressed with improved checks. This issue is fixed in Safari 18.3, visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. Processing maliciously crafted web content may lead to memory corruption.

A flaw was found in Samba. The smbd service daemon does not pick up group membership changes when re-authenticating an expired SMB session. This issue can expose file shares until clients disconnect and then connect again.

Squid is a caching proxy for the Web. In versions 6.3 and below, Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN due to incorrect buffer management. This has been fixed in version 6.4. To work around this issue, disable URN access permissions.

In iperf before 3.19.1, net.c has a buffer overflow when --skip-rx-copy is used (for MSG_TRUNC in recv).

In iperf before 3.19.1, iperf_auth.c has a Base64Decode assertion failure and application exit upon a malformed authentication attempt.

In iperf before 3.19.1, iperf_auth.c has an off-by-one error and resultant heap-based buffer overflow.

A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.

It was discovered, that redis, a persistent key-value database, due to a packaging issue, is prone to a (Debian-specific) Lua sandbox escape, which could result in remote code execution.

In FreeBSD 12.1-STABLE before r364644, 11.4-STABLE before r364651, 12.1-RELEASE before p9, 11.4-RELEASE before p3, and 11.3-RELEASE before p13, improper handling in the kernel causes a use-after-free bug by sending large user messages from multiple threads on the same SCTP socket. The use-after-free situation may result in unintended kernel behaviour including a kernel panic.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix race between cache write completion and ALL_QUEUED being set\n\nWhen netfslib is issuing subrequests, the subrequests start processing\nimmediately and may complete before we reach the end of the issuing\nfunction. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED\nto indicate to the collector that we aren't going to issue any more subreqs\nand that it can do the final notifications and cleanup.\n\nNow, this isn't a problem if the request is synchronous\n(NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be\ndone in-thread and we're guaranteed an opportunity to run the collector.\n\nHowever, if the request is asynchronous, collection is primarily triggered\nby the termination of subrequests queuing it on a workqueue. Now, a race\ncan occur here if the app thread sets ALL_QUEUED after the last subrequest\nterminates.\n\nThis can happen most easily with the copy2cache code (as used by Ceph)\nwhere, in the collection routine of a read request, an asynchronous write\nrequest is spawned to copy data to the cache. Folios are added to the\nwrite request as they're unlocked, but there may be a delay before\nALL_QUEUED is set as the write subrequests may complete before we get\nthere.\n\nIf all the write subreqs have finished by the ALL_QUEUED point, no further\nevents happen and the collection never happens, leaving the request\nhanging.\n\nFix this by queuing the collector after setting ALL_QUEUED. This is a bit\nheavy-handed and it may be sufficient to do it only if there are no extant\nsubreqs.\n\nAlso add a tracepoint to cross-reference both requests in a copy-to-request\noperation and add a trace to the netfs_rreq tracepoint to indicate the\nsetting of ALL_QUEUED.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: backend: fix out-of-bound write\n\nThe buffer is set to 80 character. If a caller write more characters,\ncount is truncated to the max available space in "simple_write_to_buffer".\nBut afterwards a string terminator is written to the buffer at offset count\nwithout boundary check. The zero termination is written OUT-OF-BOUND.\n\nAdd a check that the given buffer is smaller then the buffer to prevent.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: cpu_ops_sbi: Use static array for boot_data\n\nSince commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk\nallocator"), if NUMA is enabled, the page percpu allocator may be used\non very sparse configurations, or when requested on boot with\npercpu_alloc=page.\n\nIn that case, percpu data gets put in the vmalloc area. However,\nsbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,\nand simply assumes that __pa() would work. This causes the just started\nhart to immediately access an invalid address and hang.\n\nFortunately, struct sbi_hart_boot_data is not too large, so we can\nsimply allocate an array for boot_data statically, putting it in the\nkernel image.\n\nThis fixes NUMA=y SMP boot on Sophgo SG2042.\n\nTo reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then\nrun with:\n\n qemu-system-riscv64 -M virt -smp 2 -nographic \\\n -kernel arch/riscv/boot/Image \\\n -append "percpu_alloc=page"\n\nKernel output:\n\n[ 0.000000] Booting Linux on hartid 0\n[ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025\n...\n[ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712\n...\n[ 0.083192] smp: Bringing up secondary CPUs ...\n[ 0.086722] ------------[ cut here ]------------\n[ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)\n[ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8\n[ 0.088376] Modules linked in:\n[ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE\n[ 0.088833] Hardware name: riscv-virtio,qemu (DT)\n[ 0.088948] epc : __virt_to_phys+0xae/0xe8\n[ 0.089001] ra : __virt_to_phys+0xae/0xe8\n[ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0\n[ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976\n[ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0\n[ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000\n[ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000\n[ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000\n[ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001\n[ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec\n[ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000\n[ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7\n[ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8\n[ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003\n[ 0.090101] [] __virt_to_phys+0xae/0xe8\n[ 0.090228] [] sbi_cpu_start+0x6e/0xe8\n[ 0.090247] [] __cpu_up+0x1e/0x8c\n[ 0.090260] [] bringup_cpu+0x42/0x258\n[ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c\n[ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc\n[ 0.090320] [] _cpu_up+0x11a/0x244\n[ 0.090334] [] cpu_up+0x52/0x90\n[ 0.090384] [] bringup_nonboot_cpus+0x78/0x118\n[ 0.090411] [] smp_init+0x34/0xb8\n[ 0.090425] [] kernel_init_freeable+0x148/0x2e4\n[ 0.090442] [] kernel_init+0x1e/0x14c\n[ 0.090455] [] ret_from_fork_kernel+0xe/0xf0\n[ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18\n[ 0.090560] ---[ end trace 0000000000000000 ]---\n[ 1.179875] CPU1: failed to come online\n[ 1.190324] smp: Brought up 1 node, 1 CPU

The regcomp function in the GNU C library version from 2.4 to 2.41 is \nsubject to a double free if some previous allocation fails. It can be \naccomplished either by a malloc failure or by using an interposed malloc\nthat injects random malloc failures. The double free can allow buffer \nmanipulation depending of how the regex is constructed. This issue \naffects all architectures and ABIs supported by the GNU C library.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: always refresh the queue when reading sock\n\nAfter recent changes in net-next TCP compacts skbs much more\naggressively. This unearthed a bug in TLS where we may try\nto operate on an old skb when checking if all skbs in the\nqueue have matching decrypt state and geometry.\n\n BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]\n (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)\n Read of size 4 at addr ffff888013085750 by task tls/13529\n\n CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme\n Call Trace:\n kasan_report+0xca/0x100\n tls_strp_check_rcv+0x898/0x9a0 [tls]\n tls_rx_rec_wait+0x2c9/0x8d0 [tls]\n tls_sw_recvmsg+0x40f/0x1aa0 [tls]\n inet_recvmsg+0x1c3/0x1f0\n\nAlways reload the queue, fast path is to have the record in the queue\nwhen we wake, anyway (IOW the path going down "if !strp->stm.full_len").

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()\n\nUse pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a\npotential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe()\n\nAdd check for the return value of rcar_gen4_ptp_alloc()\nto prevent potential null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data\n\nWhen num_parents is 4, __clk_register() occurs an out-of-bounds\nwhen accessing parent_names member. Use ARRAY_SIZE() instead of\nhardcode number here.\n\n BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8\n Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59\n Hardware name: NXP i.MX95 19X19 board (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x8c/0xcc\n print_report+0x398/0x5fc\n kasan_report+0xd4/0x114\n __asan_report_load8_noabort+0x20/0x2c\n __clk_register+0x1844/0x20d8\n clk_hw_register+0x44/0x110\n __clk_hw_register_mux+0x284/0x3a8\n imx95_bc_probe+0x4f4/0xa70

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "riscv: Define TASK_SIZE_MAX for __access_ok()"\n\nThis reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for\n__access_ok()").\n\nThis commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(),\nbecause the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some\ncomputation.\n\nThe reasoning was that all user addresses are less than LONG_MAX, and all\nkernel addresses are greater than LONG_MAX. Therefore access_ok() can\nfilter kernel addresses.\n\nAddresses between TASK_SIZE and LONG_MAX are not valid user addresses, but\naccess_ok() let them pass. That was thought to be okay, because they are\nnot valid addresses at hardware level.\n\nUnfortunately, one case is missed: get_user_pages_fast() happily accepts\naddresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses\nget_user_pages_fast(). This causes the problem reported by Robert [1].\n\nTherefore, revert this commit. TASK_SIZE_MAX is changed to the default:\nTASK_SIZE.\n\nThis unfortunately reduces performance, because TASK_SIZE is more expensive\nto compute compared to LONG_MAX. But correctness first, we can think about\noptimization later, if required.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd: pmf: Use device managed allocations\n\nIf setting up smart PC fails for any reason then this can lead to\na double free when unloading amd-pmf. This is because dev->buf was\nfreed but never set to NULL and is again freed in amd_pmf_remove().\n\nTo avoid subtle allocation bugs in failures leading to a double free\nchange all allocations into device managed allocations.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: displayport: Fix potential deadlock\n\nThe deadlock can occur due to a recursive lock acquisition of\n`cros_typec_altmode_data::mutex`.\nThe call chain is as follows:\n1. cros_typec_altmode_work() acquires the mutex\n2. typec_altmode_vdm() -> dp_altmode_vdm() ->\n3. typec_altmode_exit() -> cros_typec_altmode_exit()\n4. cros_typec_altmode_exit() attempts to acquire the mutex again\n\nTo prevent this, defer the `typec_altmode_exit()` call by scheduling\nit rather than calling it directly from within the mutex-protected\ncontext.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nMemory safety bugs present in Firefox ESR 128.12, Thunderbird ESR 128.12, Firefox ESR 140.0, Thunderbird ESR 140.0, Firefox 140, and Thunderbird 140. Some of these bugs showed evidence of memory corruption, and we presume that with enough effort, some of these could have been exploited to run arbitrary code.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nMemory safety bugs are present in Firefox ESR 115.25, Firefox ESR 128.12, Thunderbird ESR 128.12, Firefox ESR 140.0, Thunderbird ESR 140.0, Firefox 140, and Thunderbird 140. Some of these bugs show evidence of memory corruption and we presume that with enough effort some of these could be exploited to run arbitrary code.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nThe JavaScript engine did not handle closed generators correctly, and it was possible to resume them, resulting in a nullptr dereference.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nXSLT document loading incorrectly propagates the source document which bypassed its CSP.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nThe username:password part is incorrectly stripped from URLs in CSP reports, potentially leaking HTTP Basic Authentication credentials.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nInsufficient escaping in the “Copy as cURL” feature could potentially be used to trick a user into executing unexpected code.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nFirefox executed javascript: URLs when used in object and embed tags.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nOn arm64, a WASM br_table instruction with a large number of entries could lead to the label being too far from the instruction, causing truncation and incorrect computation of the branch address.

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:\nOn 64-bit platforms, IonMonkey-JIT only wrote 32 bits of the 64-bit return value space on the stack. Baseline-JIT, however, reads the entire 64 bits.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight\n\nReject migration of SEV{-ES} state if either the source or destination VM\nis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the\nsection between incrementing created_vcpus and online_vcpus. The bulk of\nvCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs\nin parallel, and so sev_info.es_active can get toggled from false=>true in\nthe destination VM after (or during) svm_vcpu_create(), resulting in an\nSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.\n\nThe issue manifests most visibly as a crash when trying to free a vCPU's\nNULL VMSA page in an SEV-ES VM, but any number of things can go wrong.\n\n BUG: unable to handle page fault for address: ffffebde00000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]\n RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]\n RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]\n RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]\n RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067\n Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0\n RSP: 0018:ffff8984551978d0 EFLAGS: 00010246\n RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98\n RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000\n RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000\n R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000\n R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000\n FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0\n DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n Call Trace:\n \n sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169\n svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515\n kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396\n kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]\n kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490\n kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895\n kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310\n kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369\n __fput+0x3e4/0x9e0 fs/file_table.c:465\n task_work_run+0x1a9/0x220 kernel/task_work.c:227\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0x7f0/0x25b0 kernel/exit.c:953\n do_group_exit+0x203/0x2d0 kernel/exit.c:1102\n get_signal+0x1357/0x1480 kernel/signal.c:3034\n arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218\n do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f87a898e969\n \n Modules linked in: gq(O)\n gsmi: Log Shutdown Reason 0x03\n CR2: ffffebde00000000\n ---[ end trace 0000000000000000 ]---\n\nDeliberately don't check for a NULL VMSA when freeing the vCPU, as crashing\nthe host is likely desirable due to the VMSA being consumed by hardware.\nE.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a\nbogus VMSA page. Accessing P\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU\n\nsyzbot reports that defer/local task_work adding via msg_ring can hit\na request that has been freed:\n\nCPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n io_req_local_work_add io_uring/io_uring.c:1184 [inline]\n __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252\n io_msg_remote_post io_uring/msg_ring.c:103 [inline]\n io_msg_data_remote io_uring/msg_ring.c:133 [inline]\n __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151\n io_msg_ring_data io_uring/msg_ring.c:173 [inline]\n io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314\n __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739\n io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762\n io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874\n io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642\n io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \n\nwhich is supposed to be safe with how requests are allocated. But msg\nring requests alloc and free on their own, and hence must defer freeing\nto a sane time.\n\nAdd an rcu_head and use kfree_rcu() in both spots where requests are\nfreed. Only the one in io_msg_tw_complete() is strictly required as it\nhas been visible on the other ring, but use it consistently in the other\nspot as well.\n\nThis should not cause any other issues outside of KASAN rightfully\ncomplaining about it.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/md-bitmap: fix GPF in bitmap_get_stats()\n\nThe commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats\ncollection for external bitmaps") states:\n\n Remove the external bitmap check as the statistics should be\n available regardless of bitmap storage location.\n\n Return -EINVAL only for invalid bitmap with no storage (neither in\n superblock nor in external file).\n\nBut, the code does not adhere to the above, as it does only check for\na valid super-block for "internal" bitmaps. Hence, we observe:\n\nOops: GPF, probably for non-canonical address 0x1cd66f1f40000028\nRIP: 0010:bitmap_get_stats+0x45/0xd0\nCall Trace:\n\n seq_read_iter+0x2b9/0x46a\n seq_read+0x12f/0x180\n proc_reg_read+0x57/0xb0\n vfs_read+0xf6/0x380\n ksys_read+0x6d/0xf0\n do_syscall_64+0x8c/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nWe fix this by checking the existence of a super-block for both the\ninternal and external case.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()\n\nAdd a NULL check for msta->vif before accessing its members to prevent\na kernel panic in AP mode deployment. This also fix the issue reported\nin [1].\n\nThe crash occurs when this function is triggered before the station is\nfully initialized. The call trace shows a page fault at\nmt7925_sta_set_decap_offload() due to accessing resources when msta->vif\nis NULL.\n\nFix this by adding an early return if msta->vif is NULL and also check\nwcid.sta is ready. This ensures we only proceed with decap offload\nconfiguration when the station's state is properly initialized.\n\n[14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0\n[14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G\n[14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE\n[14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)\n[14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]\n[14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common]\n[14739.851985] sp : ffffffc085efb500\n[14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158\n[14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001\n[14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88\n[14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000\n[14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080\n[14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000\n[14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0\n[14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100\n[14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000\n[14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8\n[14739.926686] Call trace:\n[14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]\n[14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211]\n[14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211]\n[14739.946860] sta_info_move_state+0x1c/0x30 [mac80211]\n[14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211]\n[14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211]\n[14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211]\n[14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211]\n[14739.975516] genl_family_rcv_msg_doit+0xdc/0x150\n[14739.980158] genl_rcv_msg+0x218/0x298\n[14739.983830] netlink_rcv_skb+0x64/0x138\n[14739.987670] genl_rcv+0x40/0x60\n[14739.990816] netlink_unicast+0x314/0x380\n[14739.994742] netlink_sendmsg+0x198/0x3f0\n[14739.998664] __sock_sendmsg+0x64/0xc0\n[14740.002324] ____sys_sendmsg+0x260/0x298\n[14740.006242] ___sys_sendmsg+0xb4/0x110

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix potential out-of-bounds page table access during batched unmap\n\nAs pointed out by David[1], the batched unmap logic in\ntry_to_unmap_one() may read past the end of a PTE table when a large\nfolio's PTE mappings are not fully contained within a single page\ntable.\n\nWhile this scenario might be rare, an issue triggerable from userspace\nmust be fixed regardless of its likelihood. This patch fixes the\nout-of-bounds access by refactoring the logic into a new helper,\nfolio_unmap_pte_batch().\n\nThe new helper correctly calculates the safe batch size by capping the\nscan at both the VMA and PMD boundaries. To simplify the code, it also\nsupports partial batching (i.e., any number of pages from 1 up to the\ncalculated safe maximum), as there is no strong reason to special-case\nfor fully mapped folios.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: reject bs > ps block devices when THP is disabled\n\nIf THP is disabled and when a block device with logical block size >\npage size is present, the following null ptr deref panic happens during\nboot:\n\n[ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07]\n[ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380\n\n[ 13.025448] Call Trace:\n[ 13.025692] \n[ 13.025895] block_read_full_folio+0x610/0x780\n[ 13.026379] ? __pfx_blkdev_get_block+0x10/0x10\n[ 13.027008] ? __folio_batch_add_and_move+0x1fa/0x2b0\n[ 13.027548] ? __pfx_blkdev_read_folio+0x10/0x10\n[ 13.028080] filemap_read_folio+0x9b/0x200\n[ 13.028526] ? __pfx_filemap_read_folio+0x10/0x10\n[ 13.029030] ? __filemap_get_folio+0x43/0x620\n[ 13.029497] do_read_cache_folio+0x155/0x3b0\n[ 13.029962] ? __pfx_blkdev_read_folio+0x10/0x10\n[ 13.030381] read_part_sector+0xb7/0x2a0\n[ 13.030805] read_lba+0x174/0x2c0\n\n[ 13.045348] nvme_scan_ns+0x684/0x850 [nvme_core]\n[ 13.045858] ? __pfx_nvme_scan_ns+0x10/0x10 [nvme_core]\n[ 13.046414] ? _raw_spin_unlock+0x15/0x40\n[ 13.046843] ? __switch_to+0x523/0x10a0\n[ 13.047253] ? kvm_clock_get_cycles+0x14/0x30\n[ 13.047742] ? __pfx_nvme_scan_ns_async+0x10/0x10 [nvme_core]\n[ 13.048353] async_run_entry_fn+0x96/0x4f0\n[ 13.048787] process_one_work+0x667/0x10a0\n[ 13.049219] worker_thread+0x63c/0xf60\n\nAs large folio support depends on THP, only allow bs > ps block devices\nif THP is enabled.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()\n\nsyzbot found a potential access to uninit-value in nf_flow_pppoe_proto()\n\nBlamed commit forgot the Ethernet header.\n\nBUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27\n nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27\n nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623\n nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]\n nf_ingress net/core/dev.c:5742 [inline]\n __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837\n __netif_receive_skb_one_core net/core/dev.c:5975 [inline]\n __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090\n netif_receive_skb_internal net/core/dev.c:6176 [inline]\n netif_receive_skb+0x57/0x630 net/core/dev.c:6235\n tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485\n tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938\n tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0xb4b/0x1580 fs/read_write.c:686\n ksys_write fs/read_write.c:738 [inline]\n __do_sys_write fs/read_write.c:749 [inline]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race between DIM disable and net_dim()\n\nThere's a race between disabling DIM and NAPI callbacks using the dim\npointer on the RQ or SQ.\n\nIf NAPI checks the DIM state bit and sees it still set, it assumes\n`rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after\nthat check, the pointer might already be set to NULL, leading to a NULL\npointer dereference in net_dim().\n\nFix this by calling `synchronize_net()` before freeing the DIM context.\nThis ensures all in-progress NAPI callbacks are finished before the\npointer is cleared.\n\nKernel log:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:net_dim+0x23/0x190\n...\nCall Trace:\n \n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? common_interrupt+0xf/0xa0\n ? sysvec_call_function_single+0xb/0x90\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? net_dim+0x23/0x190\n ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core]\n ? sysvec_apic_timer_interrupt+0xb/0x90\n mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core]\n ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core]\n busy_poll_stop+0xa2/0x200\n ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core]\n ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core]\n __napi_busy_loop+0x345/0x3b0\n ? sysvec_call_function_single+0xb/0x90\n ? asm_sysvec_call_function_single+0x16/0x20\n ? sysvec_apic_timer_interrupt+0xb/0x90\n ? pcpu_free_area+0x1e4/0x2e0\n napi_busy_loop+0x11/0x20\n xsk_recvmsg+0x10c/0x130\n sock_recvmsg+0x44/0x70\n __sys_recvfrom+0xbc/0x130\n ? __schedule+0x398/0x890\n __x64_sys_recvfrom+0x20/0x30\n do_syscall_64+0x4c/0x100\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n...\n---[ end trace 0000000000000000 ]---\n...\n---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: vector: Fix context save/restore with xtheadvector\n\nPreviously only v0-v7 were correctly saved/restored,\nand the context of v8-v31 are damanged.\nCorrectly save/restore v8-v31 to avoid breaking userspace.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fix runtime constant support for nommu kernels\n\nthe `__runtime_fixup_32` function does not handle the case where `val` is\nzero correctly (as might occur when patching a nommu kernel and referring\nto a physical address below the 4GiB boundary whose upper 32 bits are all\nzero) because nothing in the existing logic prevents the code from taking\nthe `else` branch of both nop-checks and emitting two `nop` instructions.\n\nThis leaves random garbage in the register that is supposed to receive the\nupper 32 bits of the pointer instead of zero that when combined with the\nvalue for the lower 32 bits yields an invalid pointer and causes a kernel\npanic when that pointer is eventually accessed.\n\nThe author clearly considered the fact that if the `lui` is converted into\na `nop` that the second instruction needs to be adjusted to become an `li`\ninstead of an `addi`, hence introducing the `addi_insn_mask` variable, but\ndidn't follow that logic through fully to the case where the `else` branch\nexecutes. To fix it just adjust the logic to ensure that the second `else`\nbranch is not taken if the first instruction will be patched to a `nop`.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: Initialize UDP checksum field before checksumming\n\ncommit f1fce08e63fe ("netpoll: Eliminate redundant assignment") removed\nthe initialization of the UDP checksum, which was wrong and broke\nnetpoll IPv6 transmission due to bad checksumming.\n\nudph->check needs to be set before calling csum_ipv6_magic().

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix regression with native SMB symlinks\n\nSome users and customers reported that their backup/copy tools started\nto fail when the directory being copied contained symlink targets that\nthe client couldn't parse - even when those symlinks weren't followed.\n\nFix this by allowing lstat(2) and readlink(2) to succeed even when the\nclient can't resolve the symlink target, restoring old behavior.

In the Linux kernel, the following vulnerability has been resolved:\n\nvideo: screen_info: Relocate framebuffers behind PCI bridges\n\nApply PCI host-bridge window offsets to screen_info framebuffers. Fixes\ninvalid access to I/O memory.\n\nResources behind a PCI host bridge can be relocated by a certain offset\nin the kernel's CPU address range used for I/O. The framebuffer memory\nrange stored in screen_info refers to the CPU addresses as seen during\nboot (where the offset is 0). During boot up, firmware may assign a\ndifferent memory offset to the PCI host bridge and thereby relocating\nthe framebuffer address of the PCI graphics device as seen by the kernel.\nThe information in screen_info must be updated as well.\n\nThe helper pcibios_bus_to_resource() performs the relocation of the\nscreen_info's framebuffer resource (given in PCI bus addresses). The\nresult matches the I/O-memory resource of the PCI graphics device (given\nin CPU addresses). As before, we store away the information necessary to\nlater update the information in screen_info itself.\n\nCommit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated\nEFI framebuffers") added the code for updating screen_info. It is based\non similar functionality that pre-existed in efifb. Efifb uses a pointer\nto the PCI resource, while the newer code does a memcpy of the region.\nHence efifb sees any updates to the PCI resource and avoids the issue.\n\nv3:\n- Only use struct pci_bus_region for PCI bus addresses (Bjorn)\n- Clarify address semantics in commit messages and comments (Bjorn)\nv2:\n- Fixed tags (Takashi, Ivan)\n- Updated information on efifb

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: wcd9375: Fix double free of regulator supplies\n\nDriver gets regulator supplies in probe path with\ndevm_regulator_bulk_get(), so should not call regulator_bulk_free() in\nerror and remove paths to avoid double free.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix eswitch code memory leak in reset scenario\n\nAdd simple eswitch mode checker in attaching VF procedure and allocate\nrequired port representor memory structures only in switchdev mode.\nThe reset flows triggers VF (if present) detach/attach procedure.\nIt might involve VF port representor(s) re-creation if the device is\nconfigured is switchdev mode (not legacy one).\nThe memory was blindly allocated in current implementation,\nregardless of the mode and not freed if in legacy mode.\n\nKmemeleak trace:\nunreferenced object (percpu) 0x7e3bce5b888458 (size 40):\n comm "bash", pid 1784, jiffies 4295743894\n hex dump (first 32 bytes on cpu 45):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n pcpu_alloc_noprof+0x4c4/0x7c0\n ice_repr_create+0x66/0x130 [ice]\n ice_repr_create_vf+0x22/0x70 [ice]\n ice_eswitch_attach_vf+0x1b/0xa0 [ice]\n ice_reset_all_vfs+0x1dd/0x2f0 [ice]\n ice_pci_err_resume+0x3b/0xb0 [ice]\n pci_reset_function+0x8f/0x120\n reset_store+0x56/0xa0\n kernfs_fop_write_iter+0x120/0x1b0\n vfs_write+0x31c/0x430\n ksys_write+0x61/0xd0\n do_syscall_64+0x5b/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nTesting hints (ethX is PF netdev):\n- create at least one VF\n echo 1 > /sys/class/net/ethX/device/sriov_numvfs\n- trigger the reset\n echo 1 > /sys/class/net/ethX/device/reset

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: xsk: rx: fix the frame's length check\n\nWhen calling buf_to_xdp, the len argument is the frame data's length\nwithout virtio header's length (vi->hdr_len). We check that len with\n\n xsk_pool_get_rx_frame_size() + vi->hdr_len\n\nto ensure the provided len does not larger than the allocated chunk\nsize. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk,\nwe use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost\nto start placing data from\n\n hard_start + XDP_PACKET_HEADROOM - vi->hdr_len\nnot\n hard_start + XDP_PACKET_HEADROOM\n\nBut the first buffer has virtio_header, so the maximum frame's length in\nthe first buffer can only be\n\n xsk_pool_get_rx_frame_size()\nnot\n xsk_pool_get_rx_frame_size() + vi->hdr_len\n\nlike in the current check.\n\nThis commit adds an additional argument to buf_to_xdp differentiate\nbetween the first buffer and other ones to correctly calculate the maximum\nframe's length.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.