bpf: Fix stack-out-of-bounds write in devmap

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

drm/v3d: Stop active perfmon if it is being destroyed

If the active performance monitor (v3d->activeperfmon) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the v3d->activeperfmon pointer stale. This can lead to undefined behavior and instability.

This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").

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

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

different return values (15 and 11) from vsnprintf("%pbl ", ...)

test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:

(1) First, calculate the length of the resulting formatted string.

(2) Allocate a buffer based on the returned length.

(3) Then, perform the actual string formatting.

(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.

If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.

bpf: Cancel the running bpftimer through kworker for PREEMPTRT

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

ksmbd: track the connection owning a byte-range lock

SMB2LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llistlock.

With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbdlock and struct filelock objects.

Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llistlock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.

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

ksmbd: validate NTLMv2 response before updating session key

ksmbdauthntlmv2() derives the NTLMv2 session key into sess->sesskey before it verifies the NTLMv2 response. ksmbddecodentlmsspauthblob() then continues into KEYXCH even when ksmbdauthntlmv2() failed.

With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEYXCH and still modify sess->sesskey before STATUSLOGONFAILURE is returned.

Relevant path:

smb2sesssetup() -> conn->binding = true -> ntlmauthenticate() -> sessionuser() -> ksmbddecodentlmsspauthblob() -> ksmbdauthntlmv2() -> calcntlmv2hash() -> hmacmd5usingrawkey(..., sess->sesskey) -> cryptomemneq() returns mismatch -> KEYXCH arc4crypt(..., sess->sesskey, ...) -> outerr without expiring the binding session

Derive the base session key into a local buffer and copy it to sess->sesskey only after the proof matches. Return immediately on authentication failure so KEYXCH is only processed after successful authentication.

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

ksmbd: add a WRITEDAC/WRITEOWNER check to SMB2 SETINFO SECURITY

commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE") added a fp->daccess gate to fsctlsetsparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SETINFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2setinfosec() calls setinfosec() with no per-handle access check.

setinfosec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notifychange(), rewrites the POSIX ACL via setposixacl(), and on KSMBDSHAREFLAGACLXATTR shares removes and rewrites the Windows security descriptor via ksmbdvfssetsdxattr(). Every other persistent-mutation arm of the sibling handler smb2setinfofile() checks fp->daccess first (FILEWRITEDATA / FILEDELETE / FILEWRITEEA / FILEWRITEATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate.

A client can therefore open a handle with FILEWRITEATTRIBUTES only (no FILEWRITEDAC / FILEWRITEOWNER) and use SMB2SETINFO with InfoType SMB2OINFOSECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODEWRITE VFS backstop — the missing fp->daccess check is the entire gate.

Setting a security descriptor is the WRITEDAC / WRITEOWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUSACCESSDENIED by smb2setinfo().

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

ksmbd: require source read access for duplicate extents

FSCTLDUPLICATEEXTENTSTOFILE passes the source file directly to vfsclonefilerange() or vfscopyfilerange() without checking the SMB access mask granted to the source handle. A handle opened with attribute access can consequently be used to copy file contents into an attacker-readable destination.

Require FILEREADDATA on the source handle before either VFS operation, matching other ksmbd data-copy paths.

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

ksmbd: fix UAF of struct filelock in SMB2LOCK deferred-lock cancellation

When a blocking byte-range lock request is deferred in the FILELOCKDEFERRED path, ksmbd registers the asynchronous work into the connection's asyncrequests list via setupasyncwork(). The cancel callback smb2removeblockedlock() holds a reference to the flock.

If the lock waiter is subsequently woken up but the work state is no longer KSMBDWORKACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locksfreelock(flock) without dequeuing the work from the asyncrequests list. Concurrently, smb2cancel() walks the list under conn->requestlock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside wakeupcommon.

Fix this by restructuring the cleanup logic after the worker returns from ksmbdvfsposixlockwait(). Move listdel(&smblock->llist) and releaseasyncwork(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->requestlock before locksfreelock(flock) is called, rendering the flock unreachable for any concurrent smb2cancel().

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

ksmbd: add a permission check for FSCTLSETZERODATA

FSCTLSETZERODATA in smb2ioctl() destroys file data via ksmbdvfszerodata() -> vfsfallocate(PUNCHHOLE/ZERORANGE) after checking only the share-level KSMBDTREECONNFLAGWRITABLE, with no per-handle access check. A handle opened with only FILEWRITEATTRIBUTES still yields an FMODEWRITE filp (FILEWRITEATTRIBUTES is part of FILEWRITEDESIREACCESSLE, so smb2createopenflags() opens it OWRONLY), so the vfsfallocate FMODEWRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILEWRITEATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILEWRITEDATA right to (6/6; a FILEREADDATA-only handle was correctly denied).

This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE"). Because SETZERODATA writes data (not an attribute), require FILEWRITEDATA.

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

fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns

In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcnsfollow=2 produces a kernel slab out-of-bounds write at mount time:

BUG: KASAN: slab-out-of-bounds in logreplay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount

Two attacker-controlled fields can drive j+i past the allocated pagelcns[] array:

1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow. 2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.

Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.

This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").

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

netfilter: ebtables: move to two-stage removal scheme

Like previous patches for xtables, follow same pattern in ebtables. We can't reuse xt helpers: ebttable struct layout is incompatible.

table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.

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

netfilter: xtables: add and use xtablesunregistertableexit

Previous change added xtablesunregistertablepreexit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table: 1. The larval table has been removed already 2. existing instantiated table is no longer on the xt pernet table list.

This adds the second stage helper:

unlink the table from the dying list, free the hook ops (if any) and do the audit notification. It replaces xtunregistertable().

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

Bluetooth: SCO: Fix UAF on scosocktimeout

conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.

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

ksmbd: validate SID in parent security descriptor during ACL inheritance

Introduce smbvalidatentsdsid() helper to safely validate Owner SID and Group SID inside the NT Security Descriptor (smbntsd) retrieved from the parent directory.

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

drm/msm: Fix iommumapsgtable() return value check and avoid WARN

Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.

Store the return value in the appropriate type and in case of error, return it rather than WARNing.

Patchwork: https://patchwork.freedesktop.org/patch/719685/

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

power: reset: linkstation-poweroff: fix use-after-free in the linkstationpoweroffinit()

Move ofnodeput(dn) after the ofmatchnode() call, which still needs the node pointer. The node reference is correctly released after use.

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

ksmbd: fix wrong next length validation of ea buffer in smb2setea()

There are multiple smb2eainfo buffers in FILEFULLEAINFORMATION request from client. ksmbd find next smb2eainfo using ->NextEntryOffset of current smb2eainfo. ksmbd need to validate buffer length Before accessing the next ea. ksmbd should check buffer length using buflen, not next variable. next is the start offset of current ea that got from previous ea.

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

ksmbd: fix out-of-bound read in smb2write

ksmbdsmb2checkmessage doesn't validate hdr->NextCommand. If ->NextCommand is bigger than Offset + Length of smb2 write, It will allow oversized smb2 write length. It will cause OOB read in smb2write.

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

fs/ntfs3: Validate data run offset

This adds sanity checks for data run offset. We should make sure data run offset is legit before trying to unpack them, otherwise we may encounter use-after-free or some unexpected memory access behaviors.

[ 82.940342] BUG: KASAN: use-after-free in rununpack+0x2e3/0x570 [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240 [ 82.941670] [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15 [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 82.943720] Call Trace: [ 82.944204] <TASK> [ 82.944471] dumpstacklvl+0x49/0x63 [ 82.944908] printreport.cold+0xf5/0x67b [ 82.945141] ? waitonbit+0x106/0x120 [ 82.945750] ? rununpack+0x2e3/0x570 [ 82.946626] kasanreport+0xa7/0x120 [ 82.947046] ? rununpack+0x2e3/0x570 [ 82.947280] asanload1+0x51/0x60 [ 82.947483] rununpack+0x2e3/0x570 [ 82.947709] ? memcpy+0x4e/0x70 [ 82.947927] ? runpack+0x7a0/0x7a0 [ 82.948158] rununpackex+0xad/0x3f0 [ 82.948399] ? mienumattr+0x14a/0x200 [ 82.948717] ? rununpack+0x570/0x570 [ 82.949072] ? nienumattrex+0x1b2/0x1c0 [ 82.949332] ? nifnametype.part.0+0xd0/0xd0 [ 82.949611] ? miread+0x262/0x2c0 [ 82.949970] ? ntfscmpnamescpu+0x125/0x180 [ 82.950249] ntfsiget5+0x632/0x1870 [ 82.950621] ? ntfsgetblockbmap+0x70/0x70 [ 82.951192] ? evict+0x223/0x280 [ 82.951525] ? iput.part.0+0x286/0x320 [ 82.951969] ntfsfillsuper+0x1321/0x1e20 [ 82.952436] ? putntfs+0x1d0/0x1d0 [ 82.952822] ? vsprintf+0x20/0x20 [ 82.953188] ? mutexunlock+0x81/0xd0 [ 82.953379] ? setblocksize+0x95/0x150 [ 82.954001] gettreebdev+0x232/0x370 [ 82.954438] ? putntfs+0x1d0/0x1d0 [ 82.954700] ntfsfsgettree+0x15/0x20 [ 82.955049] vfsgettree+0x4c/0x130 [ 82.955292] pathmount+0x645/0xfd0 [ 82.955615] ? putname+0x80/0xa0 [ 82.955955] ? finishautomount+0x2e0/0x2e0 [ 82.956310] ? kmemcachefree+0x110/0x390 [ 82.956723] ? putname+0x80/0xa0 [ 82.957023] domount+0xd6/0xf0 [ 82.957411] ? pathmount+0xfd0/0xfd0 [ 82.957638] ? kasancheckwrite+0x14/0x20 [ 82.957948] x64sysmount+0xca/0x110 [ 82.958310] dosyscall64+0x3b/0x90 [ 82.958719] entrySYSCALL64afterhwframe+0x63/0xcd [ 82.959341] RIP: 0033:0x7fd0d1ce948a [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0 [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020 [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0 [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

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

fs/ntfs3: Validate buffer length while parsing index

indxread is called when we have some NTFS directory operations that need more information from the index buffers. This adds a sanity check to make sure the returned index buffer length is legit, or we may have some out-of-bound memory accesses.

[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdrfinde.isra.0+0x10c/0x320 [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245 [ 560.898760] [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37 [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 560.900170] Call Trace: [ 560.900407] <TASK> [ 560.900732] dumpstacklvl+0x49/0x63 [ 560.901108] printreport.cold+0xf5/0x689 [ 560.901395] ? hdrfinde.isra.0+0x10c/0x320 [ 560.901716] kasanreport+0xa7/0x130 [ 560.901950] ? hdrfinde.isra.0+0x10c/0x320 [ 560.902208] asanload2+0x68/0x90 [ 560.902427] hdrfinde.isra.0+0x10c/0x320 [ 560.902846] ? cmpuints+0xe0/0xe0 [ 560.903363] ? cmpsdh+0x90/0x90 [ 560.903883] ? ntfsbreadrun+0x190/0x190 [ 560.904196] ? rwsemdownreadslowpath+0x750/0x750 [ 560.904969] ? ntfsfixpostread+0xe0/0x130 [ 560.905259] ? kasancheckwrite+0x14/0x20 [ 560.905599] ? upread+0x1a/0x90 [ 560.905853] ? indxread+0x22c/0x380 [ 560.906096] indxfind+0x2ef/0x470 [ 560.906352] ? indxfindbuffer+0x2d0/0x2d0 [ 560.906692] ? kasankmalloc+0x88/0xb0 [ 560.906977] dirsearchu+0x196/0x2f0 [ 560.907220] ? ntfsnlstoutf16+0x450/0x450 [ 560.907464] ? kasancheckwrite+0x14/0x20 [ 560.907747] ? mutexlock+0x8f/0xe0 [ 560.907970] ? mutexlockslowpath+0x20/0x20 [ 560.908214] ? kmemcachealloc+0x143/0x4b0 [ 560.908459] ntfslookup+0xe0/0x100 [ 560.908788] lookupslow+0x116/0x220 [ 560.909050] ? lookupfast+0x1b0/0x1b0 [ 560.909309] ? lookupfast+0x13f/0x1b0 [ 560.909601] walkcomponent+0x187/0x230 [ 560.909944] linkpathwalk.part.0+0x3f0/0x660 [ 560.910285] ? handlelookupdown+0x90/0x90 [ 560.910618] ? pathinit+0x642/0x6e0 [ 560.911084] ? percpucounteraddbatch+0x6e/0xf0 [ 560.912559] ? allocfile+0x114/0x170 [ 560.913008] pathopenat+0x19c/0x1d10 [ 560.913419] ? getnameflags+0x73/0x2b0 [ 560.913815] ? kasansavestack+0x3a/0x50 [ 560.914125] ? kasansavestack+0x26/0x50 [ 560.914542] ? kasanslaballoc+0x6d/0x90 [ 560.914924] ? kmemcachealloc+0x143/0x4b0 [ 560.915339] ? getnameflags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? x64sysopen+0x4c/0x60 [ 560.916460] ? pathlookupat.isra.0+0x230/0x230 [ 560.916867] ? isolatefreepage+0x2e0/0x2e0 [ 560.917194] dofilpopen+0x15c/0x1f0 [ 560.917448] ? mayopendev+0x60/0x60 [ 560.917696] ? expandfiles+0xa4/0x3a0 [ 560.917923] ? kasancheckwrite+0x14/0x20 [ 560.918185] ? rawspinlock+0x88/0xdb [ 560.918409] ? rawspinlockirqsave+0x100/0x100 [ 560.918783] ? findnextbit+0x4a/0x130 [ 560.919026] ? rawspinunlock+0x19/0x40 [ 560.919276] ? allocfd+0x14b/0x2d0 [ 560.919635] dosysopenat2+0x32a/0x4b0 [ 560.920035] ? fileopenroot+0x230/0x230 [ 560.920336] ? rcureadunlock+0x5b/0x280 [ 560.920813] dosysopen+0x99/0xf0 [ 560.921208] ? filpopen+0x60/0x60 [ 560.921482] ? exittousermodeprepare+0x49/0x180 [ 560.921867] x64sysopen+0x4c/0x60 [ 560.922128] dosyscall64+0x3b/0x90 [ 560.922369] entrySYSCALL64afterhwframe+0x63/0xcd [ 560.923030] RIP: 0033:0x7f7dff2e4469 [ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIGRAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469 [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ---truncated---

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

ksmbd: fix slab-out-of-bounds in smbstrndupfromutf16()

If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2createreq().

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

ksmbd: fix session use-after-free in multichannel connection

There is a race condition between session setup and ksmbdsessionsderegister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.

bpf: Add skisinet and ISICSK check in tlsswhasctxtx/rx

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

pktgen: Avoid out-of-bounds access in getimixentries

Passing a sufficient amount of imix entries leads to invalid access to the pktdev->imixentries array because of the incorrect boundary check.

UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imixpkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl lib/dumpstack.c:117 ubsanhandleoutofbounds lib/ubsan.c:429 getimixentries net/core/pktgen.c:874 pktgenifwrite net/core/pktgen.c:1063 pdewrite fs/proc/inode.c:334 procregwrite fs/proc/inode.c:346 vfswrite fs/readwrite.c:593 ksyswrite fs/readwrite.c:644 dosyscall64 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe arch/x86/entry/entry64.S:130

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[ fp: allow to fill the array completely; minor changelog cleanup ]

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

scsi: qla2xxx: Implement ref count for SRB

The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:

qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]

Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.

When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.

If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().

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

ipv6: ioam: add NULL check for idev in ipv6hopioam()

Reported by Sashiko:

The function ipv6hopioam() accesses in6devget(skb->dev)->cnf.ioam6enabled without validating the returned idev pointer. Because addrconfifdown() can concurrently clear dev->ip6ptr via RCU, in6devget() can return NULL during interface teardown, which could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop option.

Let's add a check and use SKBDROPREASONIPV6DISABLED accordingly.

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

ksmbd: set ATTRCTIME flags when setting mtime

David reported that the new warning from setattrcopymgtime is coming like the following.

[ 113.215316] ------------[ cut here ]------------ [ 113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattrcopy+0x1ee/0x200 [ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234 [ 113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [ 113.221530] Workqueue: ksmbd-io handleksmbdwork [ksmbd] [ 113.222220] RIP: 0010:setattrcopy+0x1ee/0x200 [ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0 [ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202 [ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003 [ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0 [ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa [ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38 [ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000 [ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000 [ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0 [ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 113.234797] Call Trace: [ 113.235116] <TASK> [ 113.235393] ? warn+0x73/0xd0 [ 113.235802] ? setattrcopy+0x1ee/0x200 [ 113.236299] ? reportbug+0xf3/0x1e0 [ 113.236757] ? handlebug+0x4d/0x90 [ 113.237202] ? excinvalidop+0x13/0x60 [ 113.237689] ? asmexcinvalidop+0x16/0x20 [ 113.238185] ? setattrcopy+0x1ee/0x200 [ 113.238692] btrfssetattr+0x80/0x820 [btrfs] [ 113.239285] ? getstackinfonoinstr+0x12/0xf0 [ 113.239857] ? moduleaddress+0x22/0xa0 [ 113.240368] ? handleksmbdwork+0x6e/0x460 [ksmbd] [ 113.240993] ? moduletextaddress+0x9/0x50 [ 113.241545] ? moduleaddress+0x22/0xa0 [ 113.242033] ? unwindnextframe+0x10e/0x920 [ 113.242600] ? pfxstacktraceconsumeentry+0x10/0x10 [ 113.243268] notifychange+0x2c2/0x4e0 [ 113.243746] ? stackdepotsaveflags+0x27/0x730 [ 113.244339] ? setfilebasicinfo+0x130/0x2b0 [ksmbd] [ 113.244993] setfilebasicinfo+0x130/0x2b0 [ksmbd] [ 113.245613] ? processscheduledworks+0xbe/0x310 [ 113.246181] ? workerthread+0x100/0x240 [ 113.246696] ? kthread+0xc8/0x100 [ 113.247126] ? retfromfork+0x2b/0x40 [ 113.247606] ? retfromforkasm+0x1a/0x30 [ 113.248132] smb2setinfo+0x63f/0xa70 [ksmbd]

ksmbd is trying to set the atime and mtime via notifychange without also setting the ctime. so This patch add ATTRCTIME flags when setting mtime to avoid a warning.

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

ksmbd: fix type confusion via race condition when using ipcmsgsendrequest

req->handle is allocated using ksmbdacquireid(&ipcida), based on idaalloc. req->handle from ksmbdipcloginrequest and FSCTLPIPETRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.

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

ksmbd: fix use-after-free of a deferred filelock on double SMB2CANCEL

A deferred byte-range lock (an SMB2LOCK that blocks) registers an async work on conn->asyncrequests via setupasyncwork(), with cancelfn = smb2removeblockedlock and cancelargv[0] pointing at the struct filelock.

When the request is cancelled, the worker frees the filelock with locksfreelock() and takes the cancelled early-exit, which "goto out"s and never reaches releaseasyncwork() -- the only site that unlinks the work from conn->asyncrequests and clears cancelfn/cancelargv. The work therefore stays matchable on asyncrequests with a live cancelfn pointing at the freed filelock, until connection teardown finally runs releaseasyncwork().

smb2cancel() fires cancelfn unconditionally with no state guard, so a second SMB2CANCEL for the same AsyncId, arriving in that window, re-runs smb2removeblockedlock() on the freed filelock -- a slab use-after-free:

BUG: KASAN: slab-use-after-free in locksdeleteblock locksdeleteblock locksdeleteblock ksmbdvfsposixlockunblock smb2removeblockedlock smb2cancel <- 2nd SMB2CANCEL fires cancelfn handleksmbdwork Allocated by ...: locksalloclock <- smb2lock Freed by ...: locksfreelock <- smb2lock (cancelled branch) ... cache filelockcache of size 192

Reproduced on mainline with KASAN by an authenticated SMB client.

Skip a work whose state is already KSMBDWORKCANCELLED so its cancel callback cannot be fired a second time.