Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()<br /> <br /> A soft lockup warning was observed on a relative small system x86-64<br /> system with 16 GB of memory when running a debug kernel with kmemleak<br /> enabled.<br /> <br /> watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]<br /> <br /> The test system was running a workload with hot unplug happening in<br /> parallel. Then kemleak decided to disable itself due to its inability to<br /> allocate more kmemleak objects. The debug kernel has its<br /> CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.<br /> <br /> The soft lockup happened in kmemleak_do_cleanup() when the existing<br /> kmemleak objects were being removed and deleted one-by-one in a loop via a<br /> workqueue. In this particular case, there are at least 40,000 objects<br /> that need to be processed and given the slowness of a debug kernel and the<br /> fact that a raw_spinlock has to be acquired and released in<br /> __delete_object(), it could take a while to properly handle all these<br /> objects.<br /> <br /> As kmemleak has been disabled in this case, the object removal and<br /> deletion process can be further optimized as locking isn&amp;#39;t really needed. <br /> However, it is probably not worth the effort to optimize for such an edge<br /> case that should rarely happen. So the simple solution is to call<br /> cond_resched() at periodic interval in the iteration loop to avoid soft<br /> lockup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not allow relocation of partially dropped subvolumes<br /> <br /> [BUG]<br /> There is an internal report that balance triggered transaction abort,<br /> with the following call trace:<br /> <br /> item 85 key (594509824 169 0) itemoff 12599 itemsize 33<br /> extent refs 1 gen 197740 flags 2<br /> ref#0: tree block backref root 7<br /> item 86 key (594558976 169 0) itemoff 12566 itemsize 33<br /> extent refs 1 gen 197522 flags 2<br /> ref#0: tree block backref root 7<br /> ...<br /> BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0<br /> BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117<br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -117)<br /> WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]<br /> <br /> And btrfs check doesn&amp;#39;t report anything wrong related to the extent<br /> tree.<br /> <br /> [CAUSE]<br /> The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t<br /> have the backref for 594526208.<br /> <br /> The extent tree only have the following two backrefs around that bytenr<br /> on-disk:<br /> <br /> item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33<br /> refs 1 gen 197740 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33<br /> refs 1 gen 197522 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> <br /> But the such missing backref item is not an corruption on disk, as the<br /> offending delayed ref belongs to subvolume 934, and that subvolume is<br /> being dropped:<br /> <br /> item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439<br /> generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328<br /> last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0<br /> drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2<br /> level 2 generation_v2 198229<br /> <br /> And that offending tree block 594526208 is inside the dropped range of<br /> that subvolume. That explains why there is no backref item for that<br /> bytenr and why btrfs check is not reporting anything wrong.<br /> <br /> But this also shows another problem, as btrfs will do all the orphan<br /> subvolume cleanup at a read-write mount.<br /> <br /> So half-dropped subvolume should not exist after an RW mount, and<br /> balance itself is also exclusive to subvolume cleanup, meaning we<br /> shouldn&amp;#39;t hit a subvolume half-dropped during relocation.<br /> <br /> The root cause is, there is no orphan item for this subvolume.<br /> In fact there are 5 subvolumes from around 2021 that have the same<br /> problem.<br /> <br /> It looks like the original report has some older kernels running, and<br /> caused those zombie subvolumes.<br /> <br /> Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot<br /> deletion not triggered on mount") has long fixed the bug.<br /> <br /> [ENHANCEMENT]<br /> For repairing such old fs, btrfs-progs will be enhanced.<br /> <br /> Considering how delayed the problem will show up (at run delayed ref<br /> time) and at that time we have to abort transaction already, it is too<br /> late.<br /> <br /> Instead here we reject any half-dropped subvolume for reloc tree at the<br /> earliest time, preventing confusion and extra time wasted on debugging<br /> similar bugs.

Under heavy system utilization a random race condition can occur during authentication or token refresh operation. This flaw allows one user to be granted a token intended for another user, resulting in impersonation until the session is ended. This flaw cannot be intentionally exploited due to the required concurring action by two users. However, if the event occurs a user would be inadvertently exposed to another user’s system rights and data access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock<br /> <br /> When netpoll is enabled, calling pr_warn_once() while holding<br /> kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock<br /> inversion with the netconsole subsystem. This occurs because<br /> pr_warn_once() may trigger netpoll, which eventually leads to<br /> __alloc_skb() and back into kmemleak code, attempting to reacquire<br /> kmemleak_lock.<br /> <br /> This is the path for the deadlock.<br /> <br /> mem_pool_alloc()<br /> -&gt; raw_spin_lock_irqsave(&amp;kmemleak_lock, flags);<br /> -&gt; pr_warn_once()<br /> -&gt; netconsole subsystem<br /> -&gt; netpoll<br /> -&gt; __alloc_skb<br /> -&gt; __create_object<br /> -&gt; raw_spin_lock_irqsave(&amp;kmemleak_lock, flags);<br /> <br /> Fix this by setting a flag and issuing the pr_warn_once() after<br /> kmemleak_lock is released.

A vulnerability was determined in Ascensio System SIA OnlyOffice up to 12.7.0. Impacted is an unknown function of the file /Products/Projects/Messages.aspx of the component Comment Handler. Executing manipulation can lead to cross site scripting. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was informed early about this issue and replied: "We are already working on this case, and the issues will be resolved in one of the upcoming patches."

A vulnerability was found in Ascensio System SIA OnlyOffice up to 12.7.0. This issue affects some unknown processing of the file /Products/Projects/Messages.aspx of the component SVG Image Handler. Performing manipulation results in cross site scripting. The attack may be initiated remotely. The exploit has been made public and could be used. The vendor was informed early about this issue and replied: "We are already working on this case, and the issues will be resolved in one of the upcoming patches."

[This CNA information record relates to multiple CVEs; the<br /> text explains which aspects/vulnerabilities correspond to which CVE.]<br /> <br /> There are multiple issues related to the handling and accessing of guest<br /> memory pages in the viridian code:<br /> <br /> 1. A NULL pointer dereference in the updating of the reference TSC area.<br /> This is CVE-2025-27466.<br /> <br /> 2. A NULL pointer dereference by assuming the SIM page is mapped when<br /> a synthetic timer message has to be delivered. This is<br /> CVE-2025-58142.<br /> <br /> 3. A race in the mapping of the reference TSC page, where a guest can<br /> get Xen to free a page while still present in the guest physical to<br /> machine (p2m) page tables. This is CVE-2025-58143.

[This CNA information record relates to multiple CVEs; the<br /> text explains which aspects/vulnerabilities correspond to which CVE.]<br /> <br /> There are multiple issues related to the handling and accessing of guest<br /> memory pages in the viridian code:<br /> <br /> 1. A NULL pointer dereference in the updating of the reference TSC area.<br /> This is CVE-2025-27466.<br /> <br /> 2. A NULL pointer dereference by assuming the SIM page is mapped when<br /> a synthetic timer message has to be delivered. This is<br /> CVE-2025-58142.<br /> <br /> 3. A race in the mapping of the reference TSC page, where a guest can<br /> get Xen to free a page while still present in the guest physical to<br /> machine (p2m) page tables. This is CVE-2025-58143.

[This CNA information record relates to multiple CVEs; the<br /> text explains which aspects/vulnerabilities correspond to which CVE.]<br /> <br /> There are two issues related to the mapping of pages belonging to other<br /> domains: For one, an assertion is wrong there, where the case actually<br /> needs handling. A NULL pointer de-reference could result on a release<br /> build. This is CVE-2025-58144.<br /> <br /> And then the P2M lock isn&amp;#39;t held until a page reference was actually<br /> obtained (or the attempt to do so has failed). Otherwise the page can<br /> not only change type, but even ownership in between, thus allowing<br /> domain boundaries to be violated. This is CVE-2025-58145.

[This CNA information record relates to multiple CVEs; the<br /> text explains which aspects/vulnerabilities correspond to which CVE.]<br /> <br /> There are two issues related to the mapping of pages belonging to other<br /> domains: For one, an assertion is wrong there, where the case actually<br /> needs handling. A NULL pointer de-reference could result on a release<br /> build. This is CVE-2025-58144.<br /> <br /> And then the P2M lock isn&amp;#39;t held until a page reference was actually<br /> obtained (or the attempt to do so has failed). Otherwise the page can<br /> not only change type, but even ownership in between, thus allowing<br /> domain boundaries to be violated. This is CVE-2025-58145.

In Content Management versions 20.4- 25.3 authenticated attackers may exploit a complex cache poisoning technique to download unprotected files from the server if the filenames are known.

[This CNA information record relates to multiple CVEs; the<br /> text explains which aspects/vulnerabilities correspond to which CVE.]<br /> <br /> There are multiple issues related to the handling and accessing of guest<br /> memory pages in the viridian code:<br /> <br /> 1. A NULL pointer dereference in the updating of the reference TSC area.<br /> This is CVE-2025-27466.<br /> <br /> 2. A NULL pointer dereference by assuming the SIM page is mapped when<br /> a synthetic timer message has to be delivered. This is<br /> CVE-2025-58142.<br /> <br /> 3. A race in the mapping of the reference TSC page, where a guest can<br /> get Xen to free a page while still present in the guest physical to<br /> machine (p2m) page tables. This is CVE-2025-58143.