.NET Information Disclosure Vulnerability

.NET Security Feature Bypass Vulnerability

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: clone set on flush only

Syzbot with fault injection triggered a failing memory allocation with GFPKERNEL which results in a WARN splat:

iter.err WARNING: net/netfilter/nftablesapi.c:845 at nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> nftreleasetable+0xceb/0x11f0 net/netfilter/nftablesapi.c:12115 nftrcvnlevent+0xc25/0xdb0 net/netfilter/nftablesapi.c:12187 notifiercallchain+0x19d/0x3a0 kernel/notifier.c:85 blockingnotifiercallchain+0x6a/0x90 kernel/notifier.c:380 netlinkrelease+0x123b/0x1ad0 net/netlink/afnetlink.c:761 sockrelease net/socket.c:662 [inline] sockclose+0xc3/0x240 net/socket.c:1455

Restrict set clone to the flush set command in the preparation phase. Add NFTITERUPDATECLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used.

As for the existing NFTITERUPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set.

An alternative approach to NFTITERUPDATECLONE is to add a .clone interface and call it from the flush set path.

IBM Langflow OSS 1.0.0 through 1.11.2 Langflow could allow an authenticated attacker to write arbitrary files to the server due to improper input validation in the SaveToFileComponent. The application constructs local file paths using attacker‑controlled input without sufficient sanitization when handling requests to the /api/v1/run/{flowid} endpoint. An attacker with low‑privileged authenticated access (such as a valid API key or user session) can supply crafted path values, including absolute paths or path traversal sequences, allowing arbitrary file writes to locations writable by the Langflow process. Successful exploitation may lead to unauthorized file creation or modification, potentially resulting in further compromise depending on the deployment environment.

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot " sequences ( /.. /) to view arbitrary files on the system.

IBM Langflow OSS 1.0.0 through 1.10.2 could allow an authenticated attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system.

.NET Spoofing Vulnerability

An improper link resolution before file access vulnerability exists in the Palo Alto Networks Prisma® Access Agent on Linux platforms that enables a local low privileged user to delete system files in a limited scope and disable Prisma Access Agent.

The Prisma Access Agent on macOS, Windows, iOS, Android, and Chrome OS is not affected.

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery (SSRF) vulnerability.

In the Linux kernel, the following vulnerability has been resolved:

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to path traversal.

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to improper validation of symbolic links.

IBM Langflow OSS 1.0.0 through 1.11.2 suffer from a stored cross-site scripting vulnerability in the Playground chat interface.

IBM Langflow OSS 1.0.0 through 1.11.2 allows remote authenticated attackers to bypass localhost-only MCP configuration installation by spoofing X-Forwarded-For: 127.0.0.1 header, enabling arbitrary writes to IDE config files (~/.cursor/mcp.json, etc.).

In the Linux kernel, the following vulnerability has been resolved:

posix-cpu-timers: Fix pid refcount leak in docpunanosleep() error path

In docpunanosleep(), posixcputimercreate() takes a pid reference via getpid() and stores it in timer.it.cpu.pid. If the subsequent posixcputimerset() call fails, the function returns immediately without calling posixcputimerdel() to release the pid reference, causing a leak.

Fix it by calling posixcputimerdel() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.

In the Linux kernel, the following vulnerability has been resolved:

proc: protect ptracemayaccess() with execupdatelock (part 1)

Fix the easy cases where procfs currently calls ptracemayaccess() without execupdatelock protection, where the fix is to simply add the extra lock or use mmaccess():

- dotaskstat(): grab execupdatelock - procpidwchan(): grab execupdatelock - procmapfileslookup(): use mmaccess() instead of gettaskmm() - procmapfilesreaddir(): use mmaccess() instead of gettaskmm() - procnsgetlink(): grab execupdatelock - procnsreadlink(): grab execupdatelock

cpufreq: Fix hotplug-suspend race during reboot

In the Linux kernel, the following vulnerability has been resolved:

s390: Revert support for DCACHEWORDACCESS

loadunalignedzeropad() reads eight bytes from unaligned addresses and may cross page boundaries. It handles exceptions which may happen if reading from the second page results in an exception.

For pages which are donated to the Ultravisor for secure execution purposes the dosecurestorageaccess() exception handler however does not handle such exceptions correctly. Such an exception may result in an endless exception loop which will never be resolved.

An attempt to fix this [1] turned out to be not sufficient. For now revert loadunalignedzeropad() until this problem has been resolved in a proper way.

Note that the implementation of loadunalignedzeropad() itself is correct. The revert is just a temporary workaround until there is complete fix for secure storage access exceptions.

[1] commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory")

In the Linux kernel, the following vulnerability has been resolved:

firmwareloader: fix device reference leak in firmwareuploadregister()

firmwareuploadregister() -> fwcreateinstance() -> deviceinitialize()

After fwcreateinstance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fwcreateinstance() has already called deviceinitialize().

In firmwareuploadregister(), if alloclookupfwpriv() fails after fwcreateinstance() succeeds, the code reaches freefwsysfs and frees fwsysfs directly instead of releasing the device reference with putdevice(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak.

The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using putdevice(fwdev) in the failure path and letting fwdevrelease() handle the final cleanup, instead of freeing the instance directly from the error path.

In the Linux kernel, the following vulnerability has been resolved:

iouring/io-wq: re-check IOWQBITEXIT for each linked work item

commit 10dc95939817 ("iouring/io-wq: check IOWQBITEXIT inside work run loop") fixed the obvious case where ioworkerhandlework() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.

ioworkerhandlework() now re-checks IOWQBITEXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If iowqexitstart() sets IOWQBITEXIT after the first linked item has started, the remaining linked items can still reuse stale dokill = false, skip IOWQWORKCANCEL, and continue running after exit has begun.

Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.

In the Linux kernel, the following vulnerability has been resolved:

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: synproxy: add mutex to guard hook reference counting

As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.

Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.

In the Linux kernel, the following vulnerability has been resolved:

mailbox: add sanity check for channel array

Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftfib: fix stale stack leak via the OIFNAME register

For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.

The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.

Fix both:

- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and

- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xtables: avoid leaking percpu counter pointers

The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.

On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by xtables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.

Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xtables: restrict several matches to inet family

This is a partial revert of:

commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTOUNSPEC in more extensions")

to allow ipv4 and ipv6 only.

- xtmac - xtowner - xtphysdev

These extensions are not used by ebtables in userspace.

Moreover, xtrealm is only for ipv4, since dst->tclassid is ipv4 specific.

In the Linux kernel, the following vulnerability has been resolved:

nexthop: fix IPv6 route referencing IPv4 nexthop

syzbot reported a panic [1] [2].

When an IPv6 nexthop is replaced with an IPv4 nexthop, the hasv4 flag of all groups containing this nexthop is not updated. This is because nhgroupv4update is only called when replacing AFINET to AFINET6, but the reverse direction (AFINET6 to AFINET) is missed.

This allows a stale hasv4=false to bypass fib6checknexthop, causing IPv6 routes to be attached to groups that effectively contain only AFINET members. Subsequent route lookups then call nexthopfib6nh() which returns NULL for the AFINET member, leading to a NULL pointer dereference.

Fix by calling nhgroupv4update whenever the family changes, not just AFINET to AFINET6.

Reproducer: # AFINET6 blackhole ip -6 nexthop add id 1 blackhole # group with hasv4=false ip nexthop add id 100 group 1 # replace with AFINET (no -6), hasv4 stays false ip nexthop replace id 1 blackhole # pass stale hasv4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1

[1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftct: fix missing expect put in obj eval

nftctexpectobjeval() allocates an expectation and may call nfctexpectrelated(), but never drops its local reference.

Add nfctexpectput(exp) before return to balance allocation.