Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t irele after failing to iget in xfs_attri_recover_work<br /> <br /> xlog_recovery_iget* never set @ip to a valid pointer if they return<br /> an error, so this irele will walk off a dangling pointer. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix not releasing workqueue on .release()<br /> <br /> The workqueue associated with an DSA/IAA device is not released when<br /> the object is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: always drain queued discard work in ext4_mb_release()<br /> <br /> While reviewing recent ext4 patch[1], Sashiko raised the following<br /> concern[2]:<br /> <br /> &gt; If the filesystem is initially mounted with the discard option,<br /> &gt; deleting files will populate sbi-&gt;s_discard_list and queue<br /> &gt; s_discard_work. If it is then remounted with nodiscard, the<br /> &gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is<br /> &gt; neither cancelled nor flushed.<br /> <br /> [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/<br /> [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev<br /> <br /> The concern was valid, but it had nothing to do with the patch[1].<br /> One of the problems with Sashiko in its current (early) form is that<br /> it will detect pre-existing issues and report it as a problem with the<br /> patch that it is reviewing.<br /> <br /> In practice, it would be hard to hit deliberately (unless you are a<br /> malicious syzkaller fuzzer), since it would involve mounting the file<br /> system with -o discard, and then deleting a large number of files,<br /> remounting the file system with -o nodiscard, and then immediately<br /> unmounting the file system before the queued discard work has a change<br /> to drain on its own.<br /> <br /> Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this<br /> concern when analyzing future patches to mballoc.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths<br /> <br /> During code review, Joseph found that ext4_fc_replay_inode() calls<br /> ext4_get_fc_inode_loc() to get the inode location, which holds a<br /> reference to iloc.bh that must be released via brelse().<br /> <br /> However, several error paths jump to the &amp;#39;out&amp;#39; label without<br /> releasing iloc.bh:<br /> <br /> - ext4_handle_dirty_metadata() failure<br /> - sync_dirty_buffer() failure<br /> - ext4_mark_inode_used() failure<br /> - ext4_iget() failure<br /> <br /> Fix this by introducing an &amp;#39;out_brelse&amp;#39; label placed just before<br /> the existing &amp;#39;out&amp;#39; label to ensure iloc.bh is always released.<br /> <br /> Additionally, make ext4_fc_replay_inode() propagate errors<br /> properly instead of always returning 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: handle wraparound when searching for blocks for indirect mapped blocks<br /> <br /> Commit 4865c768b563 ("ext4: always allocate blocks only from groups<br /> inode can use") restricts what blocks will be allocated for indirect<br /> block based files to block numbers that fit within 32-bit block<br /> numbers.<br /> <br /> However, when using a review bot running on the latest Gemini LLM to<br /> check this commit when backporting into an LTS based kernel, it raised<br /> this concern:<br /> <br /> If ac-&gt;ac_g_ex.fe_group is &gt;= ngroups (for instance, if the goal<br /> group was populated via stream allocation from s_mb_last_groups),<br /> then start will be &gt;= ngroups.<br /> <br /> Does this allow allocating blocks beyond the 32-bit limit for<br /> indirect block mapped files? The commit message mentions that<br /> ext4_mb_scan_groups_linear() takes care to not select unsupported<br /> groups. However, its loop uses group = *start, and the very first<br /> iteration will call ext4_mb_scan_group() with this unsupported<br /> group because next_linear_group() is only called at the end of the<br /> iteration.<br /> <br /> After reviewing the code paths involved and considering the LLM<br /> review, I determined that this can happen when there is a file system<br /> where some files/directories are extent-mapped and others are<br /> indirect-block mapped. To address this, add a safety clamp in<br /> ext4_mb_scan_groups().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix list corruption and UAF in command complete handlers<br /> <br /> Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introduced<br /> mgmt_pending_valid(), which not only validates the pending command but<br /> also unlinks it from the pending list if it is valid. This change in<br /> semantics requires updates to several completion handlers to avoid list<br /> corruption and memory safety issues.<br /> <br /> This patch addresses two left-over issues from the aforementioned rework:<br /> <br /> 1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove()<br /> is replaced with mgmt_pending_free() in the success path. Since<br /> mgmt_pending_valid() already unlinks the command at the beginning of<br /> the function, calling mgmt_pending_remove() leads to a double list_del()<br /> and subsequent list corruption/kernel panic.<br /> <br /> 2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the error<br /> path is removed. Since the current command is already unlinked by<br /> mgmt_pending_valid(), this foreach loop would incorrectly target other<br /> pending mesh commands, potentially freeing them while they are still being<br /> processed concurrently (leading to UAFs). The redundant mgmt_cmd_status()<br /> is also simplified to use cmd-&gt;opcode directly.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14.<br /> Response headers do not vary on cookies if a session is not modified, but `SESSION_SAVE_EVERY_REQUEST` is `True`. A remote attacker can steal a user&amp;#39;s session after that user visits a cached public page.<br /> Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.<br /> Django would like to thank Cantina for reporting this issue.

Buffer Overflow vulnerability in GPAC before commit v391dc7f4d234988ea0bc3cc294eb725eddf8f702 allows an attacker to cause a denial of service via the src/scenegraph/svg_attributes.c, svg_parse_strings(), gf_svg_parse_attribute()

A flaw was found in the X.Org X server. This out-of-bounds read vulnerability in the XKB geometry processing, specifically within the `CheckSetGeom()` and `XkbAddGeomKeyAlias` functions, allows an attacker to read uninitialized or out-of-bounds memory. An attacker with a connection to the X11 server, either locally or remotely, can exploit this without user interaction. This could lead to the disclosure of memory contents or cause a denial of service by crashing the server.

A flaw was found in the X.Org X server. This vulnerability, an out-of-bounds read, affects the XKB (X Keyboard Extension) modifier map handling. An attacker with access to the X11 server can exploit this by sending a malformed request, which causes the server to read beyond its intended memory boundaries. This can lead to the exposure of sensitive information or cause the server to crash, resulting in a denial of service.

A flaw was found in Open vSwitch. When Open vSwitch is configured with a conntrack flow using FTP helpers over the userspace datapath, a remote attacker can send a specially crafted FTP stream with an EPASV command exceeding 255 characters. This heap access error can lead to a crash, resulting in a Denial of Service (DoS) for the affected system.

Allocation of Resources Without Limits or Throttling vulnerability in phoenixframework phoenix allows a denial of service via the long-poll transport&amp;#39;s NDJSON body handling.<br /> <br /> In &amp;#39;Elixir.Phoenix.Transports.LongPoll&amp;#39;:publish/4, when a POST request is received with Content-Type: application/x-ndjson, the request body is split on newline characters using String.split/2 with no limit on the number of resulting segments. An attacker can send a body consisting entirely of newline bytes, causing a 1:1 amplification into a list of empty binaries — a 1 MB body produces approximately one million list elements, an 8 MB body approximately 8.4 million. Each element is then walked by Enum.map, materializing another list of the same size. This exhausts BEAM memory and schedulers, crashing the node and terminating all active sessions.<br /> <br /> A session token required to reach the vulnerable endpoint is freely obtainable by any client via an unauthenticated GET request to the same URL with a matching Origin header, making this attack effectively unauthenticated.<br /> <br /> This issue affects phoenix: from 1.7.0 before 1.7.22 and 1.8.6.