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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

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

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.

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

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.

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

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

nfp: bpf: Add check for nfpappctrlmsgalloc()

Add check for the return value of nfpappctrlmsgalloc() in nfpbpfcmsgalloc() to prevent null pointer dereference.

Bluetooth: MGMT: Fix OOB access in parseadvmonitorpattern()

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

Bluetooth: hcisock: Prevent race in socket write iter and sock bind

There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmtpending before write iter sends the cmd, just as syzbot reported in UAF[1].

Here we use hcidevlock to synchronize the two, thereby avoiding the UAF mentioned in [1].

[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 setlinksecurity+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 sockwriteiter+0x279/0x360 net/socket.c:1195

Allocated by task 5989: mgmtpendingadd+0x35/0x140 net/bluetooth/mgmtutil.c:296 setlinksecurity+0x557/0x710 net/bluetooth/mgmt.c:1910 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 sockwriteiter+0x279/0x360 net/socket.c:1195

Freed by task 5991: mgmtpendingfree net/bluetooth/mgmtutil.c:311 [inline] mgmtpendingforeach+0x30d/0x380 net/bluetooth/mgmtutil.c:257 mgmtindexremoved+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hcisockbind+0xbe9/0x1000 net/bluetooth/hcisock.c:1314

A flaw was found in libxml2. Exponential entity expansion attack its possible bypassing all existing protection mechanisms and leading to denial of service.

GNU C Library (aka glibc or libc6) is vulnerable to a denial of service, caused by an error when processing some invalid inputs from several IBM character sets in the iconv function. By sending invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, IBM1399 encodings, a local authenticated attacker could exploit this vulnerability to cause the application to enter into an infinite loop.

GNOME libxml2 is vulnerable to a buffer overflow, caused by improper bounds checking by the xmlEncodeEntitiesInternal function in libxml2/entities.c. By persuading a victim to open a specially-crafted file, a remote attacker could overflow a buffer and execute arbitrary code on the system.

In SQLite before 3.32.3 select.c mishandles query-flattener optimization leading to a multiSelectOrderBy heap overflow because of misuse of transitive properties for constant propagation.

Last updated 25 August 2025

GNU glibc is vulnerable to a denial of service, caused by a buffer over-read in iconv feature. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to cause a SIGSEGV.

A NULL pointer dereference vulnerability exists in the xpath.c:xmlXPathCompOpEval() function of libxml2 through 2.9.8 when parsing an invalid XPath expression in the XPATHOPAND or XPATHOPOR case. Applications processing untrusted XSL format inputs with the use of the libxml2 library may be vulnerable to a denial of service attack due to a crash of the application.

GNU C Library (glibc) is vulnerable to a denial of service, caused by an error in the iconv program. By processing invalid multi-byte input sequences, a remote attacker could exploit this vulnerability to cause the application to enter into an infinite loop.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow an authenticated user to cause a denial of service using a specially crafted HTTP query due to improper allocation of system resources

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote authenticated attacker to modify data and cause a denial of service due to an SQL injection vulnerability.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a denial of service due to a heap-based out-of-bounds read. A remote attacker could send a specially crafted request that causes a limited out‑of‑bounds memory read.