A vulnerability in the Linux kernel's ksmbd component allowed sensitive SMB3 signing and encryption keys to be logged when KSMBD_DEBUG_AUTH logging was enabled. This could expose credentials through logs. The issue has been resolved by removing the logging of these keys.
In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. Such issue can be observed with the test_xdp_native_adjst_tail_shrnk_data selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pp_ref_count during page release and the following splat: WARNING: include/net/page_pool/helpers.h:297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core] [...] Call Trace: <TASK> mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core] mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core] mlx5e_close_rq+0x50/0x60 [mlx5_core] mlx5e_close_queues+0x36/0x2c0 [mlx5_core] mlx5e_close_channel+0x1c/0x50 [mlx5_core] mlx5e_close_channels+0x45/0x80 [mlx5_core] mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core] mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core] netif_set_mtu_ext+0xf1/0x230 do_setlink.isra.0+0x219/0x1180 rtnl_newlink+0x79f/0xb60 rtnetlink_rcv_msg+0x213/0x3a0 netlink_rcv_skb+0x48/0xf0 netlink_unicast+0x24a/0x350 netlink_sendmsg+0x1ee/0x410 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x232/0x280 ___sys_sendmsg+0x78/0xb0 __sys_sendmsg+0x5f/0xb0 [...] do_syscall_64+0x57/0xc50 This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags.
In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.
A Linux kernel issue was addressed where a warning (WARN_ON) was incorrectly triggered during certain VFIO passthrough configurations involving Physical Functions (PFs) and Precision Time Protocol (PTP) control. This warning occurred when the controlling PF was unavailable, which is expected behavior in some setups. The fix replaces the warning with an informational message and returns an error code instead.
A vulnerability in the Linux kernel's iwlwifi driver caused the firmware to crash by sending a 6E-related command (MCC_ALLOWED_AP_TYPE_CMD) to devices that do not support 6E, such as AX201. This issue has been resolved by preventing the command from being sent when 6E is not supported.
A vulnerability in the Linux kernel's btrfs filesystem code caused the kernel to BUG() (crash) on encountering an unexpected delayed reference type in the run_one_delayed_ref() function. This behavior has been corrected to return an error and log a message instead of crashing.
PromptHub is an all-in-one AI toolbox for prompt, skill, and agent management. From version 0.4.9 to before version 0.5.4, apps/web/src/routes/skills.ts exposes an authenticated endpoint POST /api/skills/fetch-remote that fetches a user-supplied URL server-side and reflects the response body (up to 5 MB) back to the caller. The SSRF protection in apps/web/src/utils/remote-http.ts (isPrivateIPv6) attempts to block private/loopback destinations, but multiple alternate-but-valid IPv6 representations bypass the check. The bypasses reach any IPv4 address (loopback, RFC1918, link-local) via IPv4-mapped IPv6 in hex form, and the canonical ::1 via any representation that isn't the literal string "::1". Any authenticated user (role: user or admin) can trigger the SSRF. On deployments configured with ALLOW_REGISTRATION=true — a supported and documented configuration — this means any internet user who can register. This issue has been patched in version 0.5.4.
i18nextify is a JavaScript library that adds website internationalization via a script tag, without source code changes. Versions prior to 4.0.8 substitute {{key}} interpolation tokens inside src and href attribute values with the raw string returned by i18next.t(). The substitution logic in src/localize.js (the replaceInside handler) only guards against a duplicated http:// origin prefix — it does not validate the URL scheme of the substituted value. A translated value such as javascript:alert(1) or data:text/html,<script>...</script> is applied unchanged to the live DOM attribute when an attacker can influence the content of a translation file or the translation-backend response — for example, via a compromised translation CDN, user-contributed locales, a MITM on a plain-HTTP backend, or write access to the translation JSON. This issue was patched in version 4.0.8.
`GitConfigParser.set_value()` passes values to Python's `configparser` without validating for newlines. GitPython's own `_write()` converts embedded newlines into indented continuation lines (e.g. `\n` becomes `\n\t`), but Git still accepts an indented `[core]` stanza as a section header — so the injected `core.hooksPath` becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path.
The vulnerability is not merely malformed config output: GitPython's own writer converts embedded newlines into indented continuation lines, but Git still accepts an indented `[core]` stanza as a section header, so the injected `core.hooksPath` becomes effective configuration.
This was found while auditing MLRun's `project.push()` method, which passes `author_name` and `author_email` directly to `config_writer().set_value()` with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in `.git/config`.
PoC (standalone, no MLRun required):
```python
import git, subprocess, os
repo = git.Repo("/tmp/testrepo")
with repo.config_writer() as cw:
cw.set_value("user", "name", "foo\n[core]\nhooksPath=/tmp/hooks")
r = subprocess.run(["git", "config", "core.hooksPath"], cwd="/tmp/testrepo", capture_output=True, text=True)
assert r.returncode == 0
print(r.stdout.strip()) # /tmp/hooks
os.makedirs("/tmp/hooks", exist_ok=True)
open("/tmp/hooks/pre-commit", "w").write("#!/bin/sh\nid > /tmp/pwned\n")
os.chmod("/tmp/hooks/pre-commit", 0o755)
repo.index.add(["README"])
repo.git.commit(m="test")
print(open("/tmp/pwned").read()) # uid=...
```
Tested on GitPython 3.1.46, git 2.39+.
Impact: This is persistent repo config poisoning. Any user who can supply `author_name` or `author_email` to an application calling `config_writer().set_value()` can redirect Git hook execution to an arbitrary path. In a multi-user or hosted environment (e.g. a shared MLRun server where multiple users push to the same repositories), one user can poison the `.git/config` of a shared repo and have their hooks run in the context of every subsequent Git operation by any user. On single-user deployments, the impact depends on whether the application later invokes Git hooks automatically.
Remediation: `set_value()` should raise on CR, LF, or NUL in values rather than silently pass them through:
```python
import re
if isinstance(value, (str, bytes)) and re.search(r"[\r\n\x00]", str(value)):
raise ValueError("Git config values must not contain CR, LF, or NUL")
```
Rejecting is safer than stripping — a stripped newline might indicate the caller is passing unsanitized input at a higher level, and silent normalization masks that.
Affected wherever `config_writer().set_value(section, key, user_input)` is called with external input.** GitPython is a dependency of DVC, MLflow, Kedro, and others — worth auditing their `set_value()` call sites for externally influenced inputs.
Red Hat Satellite is a system management solution that allows organizations
to configure and maintain their systems without the necessity to provide
public Internet access to their servers or other client systems. It
performs provisioning and configuration management of predefined standard
operating environments.
Security Fix(es):
* python-pillow: Pillow: Out-of-bounds Write via Specially Crafted PSD Image (CVE-2026-25990)
* candlepin: mchange-commons-java: Arbitrary code execution via JNDI dereferencing of crafted objects (CVE-2026-27727)
* python-markdown: denial of service via malformed HTML-like sequences (CVE-2025-69534)
* python-pyOpenSSL: DTLS cookie callback buffer overflow (CVE-2026-27459)
* rubygem-activesupport: Active Support: Denial of Service via large scientific notation strings (CVE-2026-33176)
Bug Fix(es):
* Satellite manifest consumer profile cert and key found in satellite client rhsm cache (SAT-43030)
* All communication should happen only over https during global registration execution (SAT-44031)
* Impossible to generate registration command via REST API in isolated networks managed by external capsules (SAT-44032)
* Executing the 'katello::clean_backend_objects' rake task takes a long time to complete (SAT-44033)
* Puppet fact parser can't create OS entry blocking Satellite leapp upgrades (SAT-44035)
* No repositories available through subscriptions on a cloud-instance host after registering it to Red Hat Satellite using global registration method (SAT-44036)
* Proxy password shown in clear text in the Overview page of Virt-who Configuration (SAT-43834)
* Non-admin users on Satellite with viewer role, unable to see the hostgroup. (SAT-44034)
Weblate is a web based localization tool. Prior to version 5.17.1, the Markdown renderer used in user comments and other user-provided content didn't properly sanitize some attributes. This issue has been patched in version 5.17.1.
A denial of service vulnerability exists in libModSecurity3 versions prior to 3.0.15. The flaw causes a segmentation fault when a rule using the t:hexDecode transformation processes a single-character query string parameter. This results in crashing worker processes and temporarily disrupting service until recovery. The issue has been fixed in version 3.0.15.