IBM Planning Analytics 2.0, and 2.1 could allow a remote authenticated attacker to execute arbitrary JavaScript due to improper output encoding.

IBM Planning Analytics 2.0, and 2.1 is vulnerable to stored cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

Last updated 25 August 2025

IBM Guardium Data Protection 12.0, 12.1, and 12.2 could allow a local attacker to obtain sensitive information due to cleartext storage of sensitive information in logs.

A flaw was found in Samba’s vfsworm module. The module is intended to provide write-once, read-many (WORM) protections by preventing modification of files after a configurable grace period. Due to insufficient validation during rename operations, an authenticated user with write access to a share could overwrite a protected file by renaming a newly created file over the existing WORM-protected file.

A vulnerability, which was classified as problematic, has been found in vercel ms up to 1.x. This issue affects the function parse of the file index.js. The manipulation of the argument str leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.0 is able to address this issue. The name of the patch is caae2988ba2a37765d055c4eee63d383320ee662. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-217451.

Code for IBM i is a Visual Studio Code extension for maintaining and compiling ILE languages on the IBMi platform. Prior to 3.0.1, src/ui/views/objectBrowser.ts stores Object Browser downloads and the edit-save flow content in the shared /tmp directory without reliable cleanup. On systems where /tmp is accessible to other local accounts, file contents remain readable after download or editing operations. This issue is fixed in version 3.0.1.

Impact

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the .unset and .omit functions. The fix for CVE-2025-13465 only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as Object.prototype, Number.prototype, and String.prototype.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

Patches

This issue is patched in 4.18.0.

Workarounds

None. Upgrade to the patched version.

Impact

Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the .unset and .omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.

The issue permits deletion of properties but does not allow overwriting their original behavior.

Patches

This issue is patched on 4.17.23.

Last updated 30 June 2026

A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elfgcsweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debugtypesamep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

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

mm/migratedevice: don't add folio to be freed to LRU in migratedevicefinalize()

If migration succeeded, we called foliomigrateflags()->memcgroupmigrate() to migrate the memcg from the old to the new folio. This will set memcgdata of the old folio to 0.

Similarly, if migration failed, memcgdata of the dst folio is left unset.

If we call folioputbacklru() on such folios (memcgdata == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

# ./hmm-tests ... # RUN hmm.hmmdeviceprivate.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VMWARNONONCEFOLIO(!memcg && !memcgroupdisabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 foliolruveclockirqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:foliolruveclockirqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.116547][T14893] ? warn.cold+0x110/0x210 [ 102.117461][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.118667][T14893] ? reportbug+0x1b9/0x320 [ 102.119571][T14893] ? handlebug+0x54/0x90 [ 102.120494][T14893] ? excinvalidop+0x17/0x50 [ 102.121433][T14893] ? asmexcinvalidop+0x1a/0x20 [ 102.122435][T14893] ? wakeupklogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dumppage+0x4f/0x60 [ 102.124352][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.125500][T14893] foliobatchmovelru+0xd4/0x200 [ 102.126577][T14893] ? pfxlruadd+0x10/0x10 [ 102.127505][T14893] foliobatchaddandmove+0x391/0x720 [ 102.128633][T14893] ? pfxlruadd+0x10/0x10 [ 102.129550][T14893] folioputbacklru+0x16/0x80 [ 102.130564][T14893] migratedevicefinalize+0x9b/0x530 [ 102.131640][T14893] dmirrormigratetodevice.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirrorfopsunlockedioctl+0x89b/0xc80

Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.

The new flow resembles what we have in migratefoliomove(): add the dst to the lru, rem ---truncated---

bpf: avoid holding freezemutex during mmap operation

acct: perform last write from workqueue

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

net: let net.core.devweight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? warn+0xcd/0x250 ? listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 syssendto+0x3bf/0x4e0 x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.devweight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueuetobacklog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).

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

team: better TEAMOPTIONTYPESTRING validation

syzbot reported following splat [1]

Make sure user-provided data contains one nul byte.

[1] BUG: KMSAN: uninit-value in stringnocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 stringnocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 requestmodule+0x252/0x9f0 kernel/module/kmod.c:149 teammodeget drivers/net/team/teamcore.c:480 [inline] teamchangemode drivers/net/team/teamcore.c:607 [inline] teammodeoptionset+0x437/0x970 drivers/net/team/teamcore.c:1401 teamoptionset drivers/net/team/teamcore.c:375 [inline] teamnloptionssetdoit+0x1339/0x1f90 drivers/net/team/teamcore.c:2662 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2543 genlrcv+0x40/0x60 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1322 [inline] netlinkunicast+0xf52/0x1260 net/netlink/afnetlink.c:1348 netlinksendmsg+0x10da/0x11e0 net/netlink/afnetlink.c:1892 socksendmsgnosec net/socket.c:718 [inline] socksendmsg+0x30f/0x380 net/socket.c:733 syssendmsg+0x877/0xb60 net/socket.c:2573 syssendmsg+0x28d/0x3c0 net/socket.c:2627 syssendmsg net/socket.c:2659 [inline] dosyssendmsg net/socket.c:2664 [inline] sesyssendmsg net/socket.c:2662 [inline] x64syssendmsg+0x212/0x3c0 net/socket.c:2662 x64syscall+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

vxlan: check vxlanvnigroupinit() return value

vxlaninit() must check vxlanvnigroupinit() success otherwise a crash happens later, spotted by syzbot.

Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlanvnigroupuninit+0x89/0x500 drivers/net/vxlan/vxlanvnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlanuninit+0x1ab/0x200 drivers/net/vxlan/vxlancore.c:2942 unregisternetdevicemanynotify+0x12d6/0x1f30 net/core/dev.c:11824 unregisternetdevicemany net/core/dev.c:11866 [inline] unregisternetdevicequeue+0x307/0x3f0 net/core/dev.c:11736 registernetdevice+0x1829/0x1eb0 net/core/dev.c:10901 vxlandevcreate+0x7c6/0xa30 drivers/net/vxlan/vxlancore.c:3981 vxlannewlink+0xd1/0x130 drivers/net/vxlan/vxlancore.c:4407 rtnlnewlinkcreate net/core/rtnetlink.c:3795 [inline] rtnlnewlink net/core/rtnetlink.c:3906 [inline]

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

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpfsendsignal() kfunc, it will cause issues because this kfunc can sleep. Change irqsdisabled() to !preemptible().

blk-cgroup: Fix class @blockclass's subsystem refcount leakage

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

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

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

OPP: fix devpmoppfindbw() when bandwidth table not initialized

If a driver calls devpmoppfindbwceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbwceil+0x50/0x88 ...

In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().

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

ASoC: soc-pcm: don't use socpcmret() on .prepare callback

commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common socpcmret(). It is used from many functions, ignoring -EINVAL is over-kill.

The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace.

So don't use socpcmret() on .prepare callback is better idea.

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

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhcihandlestoppedcmdring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhcimodcmdtimer() which crashes if curcmd was NULL.

Don't attempt timer setup if curcmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SETADDRESS forever. Everything continued working normally after several prevented crashes.

HID: hid-thrustmaster: Fix warning in thrustmasterprobe by adding endpoint check

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes.

Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low.

In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding.

The affected APIs include: ECGROUPnewcurveGF2m(), ECGROUPnewfromparams(), and various supporting BNGF2m() functions.

Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

cURL libcurl could allow a remote attacker to bypass security restrictions, caused by a flaw when using OCSP stapling to validate server cerficate. By sending a specially crafted request, an attacker could exploit this vulnerability to establish the connection even if the certificate is revoked.

App Store. A permissions issue was addressed with additional restrictions.