A use-after-free in OpenVPN 2.6.0 through 2.6.20 and 2.7alpha1 through 2.7.4 allows remote authenticated peers to potentially cause a denial of service or leak memory via crafted packets during TLS session promotion or expiry

Fixed bug (Memory corruption (zendmmheap corrupted) in opensslencrypt with AES-WRAP-PAD). (CVE-2026-14355)

GNU SASL before 2.2.4 lacks sanitization of a short challenge in gsaslntlmclientstep in the NTLM client, which could result in memory disclosure via a crafted server.

Last updated 18 August 2026

Last updated 30 June 2026

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). Prior to versions 3.4.1, 3.3.1, and 2.6.11, when the security mode is enabled, modifying the DATA Submessage within an SPDP packet sent by a publisher causes an Out-Of-Memory (OOM) condition, resulting in remote termination of Fast-DDS. If t he fields of PIDIDENTITYTOKEN or PIDPERMISSIONSTOKEN in the DATA Submessage are tampered with — specifically by ta mpering with the the vecsize value read by readOctetVector — a 32-bit integer overflow can occur, causing std::vector ::resize to request an attacker-controlled size and quickly trigger OOM and remote process termination. Versions 3.4.1, 3 .3.1, and 2.6.11 patch the issue.

NULL pointer dereference in TagSection.keys() in python-apt on APT-based Linux systems allows a local attacker to cause a denial of service (process crash) via a crafted deb822 file with a malformed non-UTF-8 key.

alinto SOGo 5.12.3 is vulnerable to Cross Site Scripting (XSS) via the "userName" parameter.

dmaengine: qcom: bamdma: Fix DT error handling for num-channels/ees

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

pcmcia: Add error handling for addinterval() in dovalidatemem()

In the dovalidatemem(), the call to addinterval() does not handle errors. If kmalloc() fails in addinterval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when subinterval() is called next.

This patch adds an error handling for the addinterval(). If addinterval() returns an error, the function will return early with the error code.

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

mm/damon/reclaim: avoid divide-by-zero in damonreclaimapplyparameters()

When creating a new scheme of DAMONRECLAIM, the calculation of 'minageregion' uses 'aggrinterval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.

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

tracing: Silence warning when chunk allocation fails in tracepidwrite

Syzkaller trigger a fault injection warning:

WARNING: CPU: 1 PID: 12326 at tracepointaddfunc+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepointaddfunc+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepointproberegisterprio+0xc0/0x110 kernel/tracepoint.c:464 registertraceprioschedswitch include/trace/events/sched.h:222 [inline] registerpidevents kernel/trace/traceevents.c:2354 [inline] eventpidwrite.isra.0+0x439/0x7a0 kernel/trace/traceevents.c:2425 vfswrite+0x24c/0x1150 fs/readwrite.c:677 ksyswrite+0x12b/0x250 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

We can reproduce the warning by following the steps below: 1. echo 8 >> seteventnotracepid. Let tr->filteredpids owns one pid and register schedswitch tracepoint. 2. echo ' ' >> seteventpid, and perform fault injection during chunk allocation of tracepidlistalloc. Let pidlist with no pid and assign to tr->filteredpids. 3. echo ' ' >> seteventpid. Let pidlist is NULL and assign to tr->filteredpids. 4. echo 9 >> seteventpid, will trigger the double register schedswitch tracepoint warning.

The reason is that syzkaller injects a fault into the chunk allocation in tracepidlistalloc, causing a failure in tracepidlistset, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to tracepidlistset.

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

mm/damon/lrusort: avoid divide-by-zero in damonlrusortapplyparameters()

Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".

DAMON's RECLAIM and LRUSORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.

Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.

This patch (of 2):

During the calculation of 'hotthres' and 'coldthres', either 'sampleinterval' or 'aggrinterval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggrinterval' is already required to be set no smaller than 'sampleinterval' in damonsetattrs(), only the case where 'sampleinterval' is zero needs to be checked.

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

mtd: rawnand: stm32fmc2: avoid overlapping mappings on ECC buffer

Avoid below overlapping mappings by using a contiguous non-cacheable buffer.

[ 4.077708] DMA-API: stm32fmc2nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 adddmaentry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: eventsunbound deferredprobeworkfunc [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : adddmaentry+0x23c/0x300 [ 4.135658] lr : adddmaentry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] adddmaentry+0x23c/0x300 [ 4.220338] debugdmamapsg+0x198/0x350 [ 4.224373] dmamapsgattrs+0xa0/0x110 [ 4.228411] dmamapsgattrs+0x10/0x2c [ 4.232247] stm32fmc2nfcxfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32fmc2nfcseqreadpage+0xc8/0x174 [ 4.242127] nandreadoob+0x1d4/0x8e0 [ 4.245861] mtdreadoobstd+0x58/0x84 [ 4.249596] mtdreadoob+0x90/0x150 [ 4.253231] mtdread+0x68/0xac

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

ocfs2: fix recursive semaphore deadlock in fiemap call

syzbot detected a OCFS2 hang due to a recursive semaphore on a FSIOCFIEMAP of the extent list on a specially crafted mmap file.

contextswitch kernel/sched/core.c:5357 [inline] schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 scheduleloop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedulepreemptdisabled+0x13/0x30 kernel/sched/core.c:7115 rwsemdownwriteslowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 downwritecommon kernel/locking/rwsem.c:1317 [inline] downwrite kernel/locking/rwsem.c:1326 [inline] downwrite+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2pagemkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 dopagemkwrite+0x14d/0x310 mm/memory.c:3361 wppageshared mm/memory.c:3762 [inline] dowppage+0x268d/0x5800 mm/memory.c:3981 handleptefault mm/memory.c:6068 [inline] handlemmfault+0x1033/0x5440 mm/memory.c:6195 handlemmfault+0x40a/0x8e0 mm/memory.c:6364 douseraddrfault+0x764/0x1390 arch/x86/mm/fault.c:1387 handlepagefault arch/x86/mm/fault.c:1476 [inline] excpagefault+0x76/0xf0 arch/x86/mm/fault.c:1532 asmexcpagefault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copyusergeneric arch/x86/include/asm/uaccess64.h:126 [inline] RIP: 0010:rawcopytouser arch/x86/include/asm/uaccess64.h:147 [inline] RIP: 0010:inlinecopytouser include/linux/uaccess.h:197 [inline] RIP: 0010:copytouser+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 <f3> a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copytouser include/linux/uaccess.h:225 [inline] fiemapfillnextextent+0x1c0/0x390 fs/ioctl.c:145 ocfs2fiemap+0x888/0xc90 fs/ocfs2/extentmap.c:806 ioctlfiemap fs/ioctl.c:220 [inline] dovfsioctl+0x1173/0x1430 fs/ioctl.c:532 dosysioctl fs/ioctl.c:596 [inline] sesysioctl+0x82/0x170 fs/ioctl.c:584 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b

ocfs2fiemap() takes a read lock of the ipallocsem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemapfillnextextent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2pagemkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem.

The ipallocsem protects the inode extent list and size. Release the read semphore before calling fiemapfillnextextent() in ocfs2fiemap() and ocfs2fiemapinline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.

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

net: fec: Fix possible NPD in fecenetphyresetafterclkenable()

The function ofphyfinddevice may return NULL, so we need to take care before dereferencing phydev.

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

tee: fix NULL pointer dereference in teeshmput

teeshmput have NULL pointer dereference:

opteedisableshmcache --> shm = regpairtoptr(...);//shm maybe return NULL teeshmfree(shm); --> teeshmput(shm);//crash

Add check in teeshmput to fix it.

panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : teeshmput+0x24/0x188 lr : teeshmfree+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: teeshmput+0x24/0x188 teeshmfree+0x14/0x28 opteedisableshmcache+0xa8/0x108 opteeshutdown+0x28/0x38 platformshutdown+0x28/0x40 deviceshutdown+0x144/0x2b0 kernelpoweroff+0x3c/0x80 hibernate+0x35c/0x388 statestore+0x64/0x80 kobjattrstore+0x14/0x28 sysfskfwrite+0x48/0x60 kernfsfopwriteiter+0x128/0x1c0 vfswrite+0x270/0x370 ksyswrite+0x6c/0x100 arm64syswrite+0x20/0x30 invokesyscall+0x4c/0x120 el0svccommon.constprop.0+0x44/0xf0 doel0svc+0x24/0x38 el0svc+0x24/0x88 el0t64synchandler+0x134/0x150 el0t64sync+0x14c/0x15

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

ppp: fix memory leak in padcompressskb

If allocskb() fails in padcompressskb(), it returns NULL without releasing the old skb. The caller does:

skb = padcompressskb(ppp, skb); if (!skb) goto drop;

drop: kfreeskb(skb);

When padcompressskb() returns NULL, the reference to the old skb is lost and kfreeskb(skb) ends up doing nothing, leading to a memory leak.

Align padcompressskb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the newskb variable so the original skb is not lost when padcompressskb() fails.

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

pcmcia: Fix a NULL pointer dereference in iodynfindioregion()

In iodynfindioregion(), pcmciamakeresource() is assigned to res and used in pcibusallocresource(). There is a dereference of res in pcibusallocresource(), which could lead to a NULL pointer dereference on failure of pcmciamakeresource().

Fix this bug by adding a check of res.

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

mm: move page table sync declarations to linux/pgtable.h

During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in initmm.pgd, but not in the page tables of other tasks.

And looking at populatesectionmemmap(): if (vmemmapcanoptimize(altmap, pgmap)) // does not sync top level page tables r = vmemmappopulatecompoundpages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmappopulate(start, end, nid, altmap);

In the normal path, vmemmappopulate() in arch/x86/mm/init64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.

However, when vmemmapcanoptimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmappopulatecompoundpages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.

We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.

It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.

The solution: Make page table sync more code robust and harder to miss

To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}populatekernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.

The new interface reuses existing ARCHPAGETABLESYNCMASK, PGTBLPDMODIFIED and archsynckernelmappings() facility used by vmalloc and ioremap to synchronize page tables.

pgdpopulatekernel() looks like this: static inline void pgdpopulatekernel(unsigned long addr, pgdt pgd, p4dt p4d) { pgdpopulate(&initmm, pgd, p4d); if (ARCHPAGETABLESYNCMASK & PGTBLPGDMODIFIED) archsynckernelmappings(addr, addr); }

It is worth noting that vmalloc() and applytorange() carefully synchronizes page tables by calling pdalloctrack() and archsynckernelmappings(), and thus they are not affected by ---truncated---

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since slaballoc() has preemption disabled, we mask out GFPDIRECTRECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 allocpagesslowpath+0x1ac allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c slaballoc+0xccc kmalloccachenoprof+0x470 setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...

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

ocfs2: prevent release journal inode after journal shutdown

Before calling ocfs2deleteosb(), ocfs2journalshutdown() has already been executed in ocfs2dismountvolume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2journalreleasejbdinode().

ocfs2dismountvolume()-> ocfs2deleteosb()-> ocfs2freeslotinfo()-> ocfs2freeslotinfo()-> evict()-> ocfs2evictinode()-> ocfs2clearinode()-> jbd2journalreleasejbdinode(osb->journal->jjournal,

Adding osb->journal checks will prevent null-ptr-deref during the above execution path.

fs/smb: Fix inconsistent refcnt update

ftrace: Fix potential warning in traceprintkseq during ftracedump

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

sctp: initialize more fields in sctpv6fromsk()

syzbot found that sin6scopeid was not properly initialized, leading to undefined behavior.

Clear sin6scopeid and sin6flowinfo.

BUG: KMSAN: uninit-value in sctpv6cmpaddr+0x887/0x8c0 net/sctp/ipv6.c:649 sctpv6cmpaddr+0x887/0x8c0 net/sctp/ipv6.c:649 sctpinet6cmpaddr+0x4f2/0x510 net/sctp/ipv6.c:983 sctpbindaddrconflict+0x22a/0x3b0 net/sctp/bindaddr.c:390 sctpgetportlocal+0x21eb/0x2440 net/sctp/socket.c:8452 sctpgetport net/sctp/socket.c:8523 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x710/0xfd0 net/sctp/socket.c:8636 syslistensocket net/socket.c:1912 [inline] syslisten net/socket.c:1927 [inline] dosyslisten net/socket.c:1932 [inline] sesyslisten net/socket.c:1930 [inline] x64syslisten+0x343/0x4c0 net/socket.c:1930 x64syscall+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls64.h:51 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd9/0x210 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable addr.i.i created at: sctpgetport net/sctp/socket.c:8515 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x650/0xfd0 net/sctp/socket.c:8636 syslistensocket net/socket.c:1912 [inline] syslisten net/socket.c:1927 [inline] dosyslisten net/socket.c:1932 [inline] sesyslisten net/socket.c:1930 [inline] x64syslisten+0x343/0x4c0 net/socket.c:1930

HID: hid-ntrig: fix unable to handle page fault in ntrigreportversion()

ACPI: processor: idle: Check acpifetchacpidev() return value

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

usb: dwc3: Remove WARNON for device endpoint command timeouts

This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'paniconwarn' is enabled and unnecessary call trace prints when 'paniconwarn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed:

1. Connect ======= ->dwc3threadinterrupt ->dwc3ep0interrupt ->configfscompositesetup ->compositesetup ->usbepqueue ->dwc3gadgetep0queue ->dwc3gadgetep0queue ->dwc3ep0docontroldata ->dwc3sendgadgetepcmd

2. Disconnect ========== ->dwc3threadinterrupt ->dwc3gadgetdisconnectinterrupt ->dwc3ep0resetstate ->dwc3ep0endcontroldata ->dwc3sendgadgetepcmd

In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USBENDPOINTHALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARNON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn.

block: avoid possible overflow for chunksectors check in blkstacklimits()