Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: always detect conflicting inodes when logging inode refs<br /> <br /> After rename exchanging (either with the rename exchange operation or<br /> regular renames in multiple non-atomic steps) two inodes and at least<br /> one of them is a directory, we can end up with a log tree that contains<br /> only of the inodes and after a power failure that can result in an attempt<br /> to delete the other inode when it should not because it was not deleted<br /> before the power failure. In some case that delete attempt fails when<br /> the target inode is a directory that contains a subvolume inside it, since<br /> the log replay code is not prepared to deal with directory entries that<br /> point to root items (only inode items).<br /> <br /> 1) We have directories "dir1" (inode A) and "dir2" (inode B) under the<br /> same parent directory;<br /> <br /> 2) We have a file (inode C) under directory "dir1" (inode A);<br /> <br /> 3) We have a subvolume inside directory "dir2" (inode B);<br /> <br /> 4) All these inodes were persisted in a past transaction and we are<br /> currently at transaction N;<br /> <br /> 5) We rename the file (inode C), so at btrfs_log_new_name() we update<br /> inode C&amp;#39;s last_unlink_trans to N;<br /> <br /> 6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B),<br /> so after the exchange "dir1" is inode B and "dir2" is inode A.<br /> During the rename exchange we call btrfs_log_new_name() for inodes<br /> A and B, but because they are directories, we don&amp;#39;t update their<br /> last_unlink_trans to N;<br /> <br /> 7) An fsync against the file (inode C) is done, and because its inode<br /> has a last_unlink_trans with a value of N we log its parent directory<br /> (inode A) (through btrfs_log_all_parents(), called from<br /> btrfs_log_inode_parent()).<br /> <br /> 8) So we end up with inode B not logged, which now has the old name<br /> of inode A. At copy_inode_items_to_log(), when logging inode A, we<br /> did not check if we had any conflicting inode to log because inode<br /> A has a generation lower than the current transaction (created in<br /> a past transaction);<br /> <br /> 9) After a power failure, when replaying the log tree, since we find that<br /> inode A has a new name that conflicts with the name of inode B in the<br /> fs tree, we attempt to delete inode B... this is wrong since that<br /> directory was never deleted before the power failure, and because there<br /> is a subvolume inside that directory, attempting to delete it will fail<br /> since replay_dir_deletes() and btrfs_unlink_inode() are not prepared<br /> to deal with dir items that point to roots instead of inodes.<br /> <br /> When that happens the mount fails and we get a stack trace like the<br /> following:<br /> <br /> [87.2314] BTRFS info (device dm-0): start tree-log replay<br /> [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259<br /> [87.2332] ------------[ cut here ]------------<br /> [87.2338] BTRFS: Transaction aborted (error -2)<br /> [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2368] Modules linked in: btrfs loop dm_thin_pool (...)<br /> [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full)<br /> [87.2489] Tainted: [W]=WARN<br /> [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2538] Code: c0 89 04 24 (...)<br /> [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286<br /> [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000<br /> [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff<br /> [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840<br /> [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0<br /> [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10<br /> [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000<br /> [87.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix NULL dereference on root when tracing inode eviction<br /> <br /> When evicting an inode the first thing we do is to setup tracing for it,<br /> which implies fetching the root&amp;#39;s id. But in btrfs_evict_inode() the<br /> root might be NULL, as implied in the next check that we do in<br /> btrfs_evict_inode().<br /> <br /> Hence, we either should set the -&gt;root_objectid to 0 in case the root is<br /> NULL, or we move tracing setup after checking that the root is not<br /> NULL. Setting the rootid to 0 at least gives us the possibility to trace<br /> this call even in the case when the root is NULL, so that&amp;#39;s the solution<br /> taken here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation<br /> <br /> Make sure to drop the reference taken when looking up the crossbar<br /> platform device during am335x route allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: stm32: dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: sh: rz-dmac: fix device leak on probe failure<br /> <br /> Make sure to drop the reference taken when looking up the ICU device<br /> during probe also on probe failures (e.g. probe deferral).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: interrupt-cnt: Drop IRQF_NO_THREAD flag<br /> <br /> An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as<br /> CONFIG_PROVE_RAW_LOCK_NESTING warns:<br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.18.0-rc1+git... #1<br /> -----------------------------<br /> some-user-space-process/1251 is trying to lock:<br /> (&amp;counter-&gt;events_list_lock){....}-{3:3}, at: counter_push_event [counter]<br /> other info that might help us debug this:<br /> context-{2:2}<br /> no locks held by some-user-space-process/....<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT<br /> Call trace:<br /> show_stack (C)<br /> dump_stack_lvl<br /> dump_stack<br /> __lock_acquire<br /> lock_acquire<br /> _raw_spin_lock_irqsave<br /> counter_push_event [counter]<br /> interrupt_cnt_isr [interrupt_cnt]<br /> __handle_irq_event_percpu<br /> handle_irq_event<br /> handle_simple_irq<br /> handle_irq_desc<br /> generic_handle_domain_irq<br /> gpio_irq_handler<br /> handle_irq_desc<br /> generic_handle_domain_irq<br /> gic_handle_irq<br /> call_on_irq_stack<br /> do_interrupt_handler<br /> el0_interrupt<br /> __el0_irq_handler_common<br /> el0t_64_irq_handler<br /> el0t_64_irq<br /> <br /> ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an<br /> alternative to switching to raw_spinlock_t, because the latter would limit<br /> all potential nested locks to raw_spinlock_t only.

The SupportCandy – Helpdesk &amp; Customer Support Ticket System plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.4.4 via the &amp;#39;add_reply&amp;#39; function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to steal file attachments uploaded by other users by specifying arbitrary attachment IDs in the &amp;#39;description_attachments&amp;#39; parameter, re-associating those files to their own tickets and removing access from the original owners.

The SupportCandy – Helpdesk &amp; Customer Support Ticket System plugin for WordPress is vulnerable to SQL Injection via the Number-type custom field filter in all versions up to, and including, 3.4.4. This is due to insufficient escaping on the user-supplied operand value when using the equals operator and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Subscriber-level access and above (customers), to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The Booking Calendar plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the wpbc_ajax_WPBC_FLEXTIMELINE_NAV() function in all versions up to, and including, 10.14.13. This makes it possible for unauthenticated attackers to retrieve booking information including customer names, phones and emails.

The Ajax Load More – Infinite Scroll, Load More, &amp; Lazy Load plugin for WordPress is vulnerable to unauthorized access of data due to incorrect authorization on the parse_custom_args() function in all versions up to, and including, 7.8.1. This makes it possible for unauthenticated attackers to expose the titles and excerpts of private, draft, pending, scheduled, and trashed posts.

The NEX-Forms – Ultimate Forms Plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the NF5_Export_Forms class constructor in all versions up to, and including, 9.1.8. This makes it possible for unauthenticated attackers to export form configurations, that may include sensitive data, such as email addresses, PayPal API credentials, and third-party integration keys by enumerating the nex_forms_Id parameter.

HotCRP is conference review software. HotCRP versions from October 2025 through January 2026 delivered documents of all types with inline Content-Disposition, causing them to be rendered in the user’s browser rather than downloaded. (The intended behavior was for only `text/plain`, `application/pdf`, `image/gif`, `image/jpeg`, and `image/png` to be delivered inline, though adding `save=0` to the document URL could request inline delivery for any document.) This made users who clicked a document link vulnerable to cross-site scripting attacks. An uploaded HTML or SVG document would run in the viewer’s browser with access to their HotCRP credentials, and Javascript in that document could eventually make arbitrary calls to HotCRP’s API. Malicious documents could be uploaded to submission fields with “file upload” or “attachment” type, or as attachments to comments. PDF upload fields were not vulnerable. A search of documents uploaded to hotcrp.com found no evidence of exploitation. The vulnerability was introduced in commit aa20ef288828b04550950cf67c831af8a525f508 (11 October 2025), present in development versions and v3.2, and fixed in commit 8933e86c9f384b356dc4c6e9e2814dee1074b323 and v3.2.1. Additionally, c3d88a7e18d52119c65df31c2cc994edd2beccc5 and v3.2.1 remove support for `save=0`.