bonding: annotate data-races around slave->lastrx

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

can: gsusb: gsusbreceivebulkcallback(): fix error message

Sinc commit 79a6d1bfe114 ("can: gsusb: gsusbreceivebulkcallback(): unanchor URL on usbsubmiturb() error") a failing resubmit URB will print an info message.

In the case of a short read where netdev has not yet been assigned, initialize as NULL to avoid dereferencing an undefined value. Also report the error value of the failed resubmit.

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

perf: Fix refcount warning on event->mmapcount increment

When calling refcountinc(&event->mmapcount) inside perfmmaprb(), the following warning is triggered:

refcountt: addition on 0; use-after-free. WARNING: lib/refcount.c:25

PoC:

struct perfeventattr attr = {0}; int fd = syscall(NRperfeventopen, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROTREAD | PROTWRITE, MAPSHARED, fd, 0); int victim = syscall(NRperfeventopen, &attr, 0, -1, fd, PERFFLAGFDOUTPUT); mmap(NULL, 0x3000, PROTREAD | PROTWRITE, MAPSHARED, victim, 0);

This occurs when creating a group member event with the flag PERFFLAGFDOUTPUT. The group leader should be mmap-ed and then mmap-ing the event triggers the warning.

Since the event has copied the outputevent in perfeventsetoutput(), event->rb is set. As a result, perfmmaprb() calls refcountinc(&event->mmapcount) when event->mmapcount = 0.

Disallow the case when event->mmapcount = 0. This also prevents two events from updating the same userpage.

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

can: usb8dev: usb8devreadbulkcallback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulkcallback(): fix URB memory leak").

In usb8devopen() -> usb8devstart(), the URBs for USB-in transfers are allocated, added to the priv->rxsubmitted anchor and submitted. In the complete callback usb8devreadbulkcallback(), the URBs are processed and resubmitted. In usb8devclose() -> unlinkallurbs() the URBs are freed by calling usbkillanchoredurbs(&priv->rxsubmitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usbkillanchoredurbs().

Fix the memory leak by anchoring the URB in the usb8devreadbulkcallback() to the priv->rxsubmitted anchor.

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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.

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

xhci: sideband: don't dereference freed ring when removing sideband endpoint

xhcisidebandremoveendpoint() incorrecly assumes that the endpoint is running and has a valid transfer ring.

Lianqin reported a crash during suspend/wake-up stress testing, and found the cause to be dereferencing a non-existing transfer ring 'ep->ring' during xhcisidebandremoveendpoint().

The endpoint and its ring may be in unknown state if this function is called after xHCI was reinitialized in resume (lost power), or if device is being re-enumerated, disconnected or endpoint already dropped.

Fix this by both removing unnecessary ring access, and by checking ep->ring exists before dereferencing it. Also make sure endpoint is running before attempting to stop it.

Remove the xhciinitializeringinfo() call during sideband endpoint removal as is it only initializes ring structure enqueue, dequeue and cycle state values to their starting values without changing actual hardware enqueue, dequeue and cycle state. Leaving them out of sync is worse than leaving it as it is. The endpoint will get freed in after this in most usecases.

If the (audio) class driver want's to reuse the endpoint after offload then it is up to the class driver to ensure endpoint is properly set up.

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

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

net: usb: rtl8150: fix memory leak on usbsubmiturb() failure

In asyncsetregisters(), when usbsubmiturb() fails, the allocated asyncreq structure and URB are not freed, causing a memory leak.

The completion callback asyncsetregcb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.

Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.

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

mptcp: ensure context reset on disconnect()

After the blamed commit below, if the MPC subflow is already in TCPCLOSE status or has fallback to TCP at mptcpdisconnect() time, mptcpdofastclose() skips setting the sendfastclose flag and the later mptcpclosessk() does not reset anymore the related subflow context.

Any later connection will be created with both the requestmptcp flag and the msk-level fallback status off (it is unconditionally cleared at MPTCP disconnect time), leading to a warning in subflowdataready():

WARNING: CPU: 26 PID: 8996 at net/mptcp/subflow.c:1519 subflowdataready (net/mptcp/subflow.c:1519 (discriminator 13)) Modules linked in: CPU: 26 UID: 0 PID: 8996 Comm: syz.22.39 Not tainted 6.18.0-rc7-05427-g11fc074f6c36 #1 PREEMPT(voluntary) Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:subflowdataready (net/mptcp/subflow.c:1519 (discriminator 13)) Code: 90 0f 0b 90 90 e9 04 fe ff ff e8 b7 1e f5 fe 89 ee bf 07 00 00 00 e8 db 19 f5 fe 83 fd 07 0f 84 35 ff ff ff e8 9d 1e f5 fe 90 <0f> 0b 90 e9 27 ff ff ff e8 8f 1e f5 fe 4c 89 e7 48 89 de e8 14 09 RSP: 0018:ffffc9002646fb30 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88813b218000 RCX: ffffffff825c8435 RDX: ffff8881300b3580 RSI: ffffffff825c8443 RDI: 0000000000000005 RBP: 000000000000000b R08: ffffffff825c8435 R09: 000000000000000b R10: 0000000000000005 R11: 0000000000000007 R12: ffff888131ac0000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f88330af6c0(0000) GS:ffff888a93dd2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88330aefe8 CR3: 000000010ff59000 CR4: 0000000000350ef0 Call Trace: <TASK> tcpdataready (net/ipv4/tcpinput.c:5356) tcpdataqueue (net/ipv4/tcpinput.c:5445) tcprcvstateprocess (net/ipv4/tcpinput.c:7165) tcpv4dorcv (net/ipv4/tcpipv4.c:1955) releasesock (include/net/sock.h:1158 (discriminator 6) net/core/sock.c:3180 (discriminator 6)) releasesock (net/core/sock.c:3737) mptcpsendmsg (net/mptcp/protocol.c:1763 net/mptcp/protocol.c:1857) inetsendmsg (net/ipv4/afinet.c:853 (discriminator 7)) syssendto (net/socket.c:727 (discriminator 15) net/socket.c:742 (discriminator 15) net/socket.c:2244 (discriminator 15)) x64syssendto (net/socket.c:2247) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f883326702d

Address the issue setting an explicit fastclosing flag at fastclose time, and checking such flag after mptcpdofastclose().

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

LoongArch: BPF: Sign extend kfunc call arguments

The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emitabiext() helper. The emitabiext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing signextend() helper and thus we can't reuse it).

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

mt76: mt7615: Fix memory leak in mt7615mcuwtblstaadd()

In mt7615mcuwtblstaadd(), an skb sskb is allocated. If the subsequent call to mt76connacmcuallocwtblreq() fails, the function returns an error without freeing sskb, leading to a memory leak.

Fix this by calling devkfreeskb() on sskb in the error handling path to ensure it is properly released.

ima: Handle error code returned by imafilterrulematch()

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

bpf: Check skb->transportheader is set in bpfskbcheckmtu

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

comedi: pcl818: fix null-ptr-deref in pcl818aicancel()

Syzbot identified an issue [1] in pcl818aicancel(), which stems from the fact that in case of early device detach via pcl818detach(), subdevice dev->readsubdev may not have initialized its pointer to &struct comediasync as intended. Thus, any such dereferencing of &s->async->cmd will lead to general protection fault and kernel crash.

Mitigate this problem by removing a call to pcl818aicancel() from pcl818detach() altogether. This way, if the subdevice setups its support for async commands, everything async-related will be handled via subdevice's own ->cancel() function in comedidevicedetachlocked() even before pcl818detach(). If no support for asynchronous commands is provided, there is no need to cancel anything either.

[1] Syzbot crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:pcl818aicancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762 ... Call Trace: <TASK> pcl818detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedidevicedetachlocked+0x178/0x750 drivers/comedi/drivers.c:207 dodevconfigioctl drivers/comedi/comedifops.c:848 [inline] comediunlockedioctl+0xcde/0x1020 drivers/comedi/comedifops.c:2178 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] ...

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

net: ethernet: ti: netcp: Standardize knavdmaopenchannel to return NULL on error

Make knavdmaopenchannel consistently return NULL on error instead of ERRPTR. Currently the header include/linux/soc/ti/knavdma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERRPTR on failure, causing inconsistency in the users. This results in a crash in netcpfreenavigatorresources as followed (trimmed):

Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] pgd=80000800207003, pmd=82ffda003, pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knavdmaclosechannel+0x30/0x19c LR is at netcpfreenavigatorresources+0x2c/0x28c

[... TRIM...]

Call trace: knavdmaclosechannel from netcpfreenavigatorresources+0x2c/0x28c netcpfreenavigatorresources from netcpndoopen+0x430/0x46c netcpndoopen from devopen+0x114/0x29c devopen from devchangeflags+0x190/0x208 devchangeflags from netifchangeflags+0x1c/0x58 netifchangeflags from devchangeflags+0x38/0xa0 devchangeflags from ipautoconfig+0x2c4/0x11f0 ipautoconfig from dooneinitcall+0x58/0x200 dooneinitcall from kernelinitfreeable+0x1cc/0x238 kernelinitfreeable from kernelinit+0x1c/0x12c kernelinit from retfromfork+0x14/0x38 [... TRIM...]

Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcpcore.c so the impact is limited.

Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcpcore: return error while dma channel open issue"), but provides a less error prone implementation.

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

mlx5: Fix default values in create CQ

Currently, CQs without a completion function are assigned the mlx5addcqtotasklet function by default. This is problematic since only user CQs created through the mlx5ib driver are intended to use this function.

Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5cqarm. However, the default CQ creation flow leaves a valid value in the CQ's armdb field, allowing FW to send interrupts to polling-only CQs in certain corner cases.

These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.

Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.

This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.

Callers of mlx5corecreatecq are responsible for changing the completion function and arming the CQ per their needs.

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

smc: Use skdstget() and dstdevrcu() in smcclcprfxmatch().

smcclcprfxmatch() is called from smclistenwork() and not under RCU nor RTNL.

Using skdstget(sk)->dev could trigger UAF.

Let's use skdstget() and dstdevrcu().

Note that the returned value of smcclcprfxmatch() is not used in the caller.

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

net/mlx5e: Check for NOTREADY flag state after locking

Currently the check for NOTREADY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unreadyflows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplinkpriv->unreadyflowslock mutex.

[0]: [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1 [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP: 0010:mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] Call Trace: [44376.406651] <TASK> [44376.406939] ? dieaddr+0x33/0x90 [44376.407311] ? excgeneralprotection+0x192/0x390 [44376.407795] ? asmexcgeneralprotection+0x22/0x30 [44376.408292] ? mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.408876] mlx5etcdelfdbpeerflow+0xbc/0xe0 [mlx5core] [44376.409482] mlx5etcdelflow+0x42/0x210 [mlx5core] [44376.410055] mlx5eflowput+0x25/0x50 [mlx5core] [44376.410529] mlx5edeleteflower+0x24b/0x350 [mlx5core] [44376.411043] tcsetupcbreoffload+0x22/0x80 [44376.411462] flreoffload+0x261/0x2f0 [clsflower] [44376.411907] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.412481] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.413044] tcfblockplaybackoffloads+0x76/0x170 [44376.413497] tcfblockunbind+0x7b/0xd0 [44376.413881] tcfblocksetup+0x17d/0x1c0 [44376.414269] tcfblockoffloadcmd.isra.0+0xf1/0x130 [44376.414725] tcfblockoffloadunbind+0x43/0x70 [44376.415153] tcfblockput+0x82/0x150 [44376.415532] ingressdestroy+0x22/0x30 [schingress] [44376.415986] qdiscdestroy+0x3b/0xd0 [44376.416343] qdiscgraft+0x4d0/0x620 [44376.416706] tcgetqdisc+0x1c9/0x3b0 [44376.417074] rtnetlinkrcvmsg+0x29c/0x390 [44376.419978] ? repmovsalternative+0x3a/0xa0 [44376.420399] ? rtnlcalcit.isra.0+0x120/0x120 [44376.420813] netlinkrcvskb+0x54/0x100 [44376.421192] netlinkunicast+0x1f6/0x2c0 [44376.421573] netlinksendmsg+0x232/0x4a0 [44376.421980] socksendmsg+0x38/0x60 [44376.422328] syssendmsg+0x1d0/0x1e0 [44376.422709] ? copymsghdrfromuser+0x6d/0xa0 [44376.423127] syssendmsg+0x80/0xc0 [44376.423495] ? sysrecvmsg+0x8b/0xc0 [44376.423869] syssendmsg+0x51/0x90 [44376.424226] dosyscall64+0x3d/0x90 [44376.424587] entrySYSCALL64afterhwframe+0x46/0xb0 [44376.425046] RIP: 0033:0x7f045134f887 [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated---

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

audit: fix out-of-bounds read in auditcomparednamepath()

When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in auditcomparednamepath().

The helper parentlen() returns 1 for "/". In auditcomparednamepath(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read.

Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access.

[PM: subject tweak, sign-off email fixes]

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

PCI: pnvphp: Clean up allocated IRQs on unplug

When the root of a nested PCIe bridge configuration is unplugged, the pnvphp driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic.

Fix this by walking all child buses and deallocating all its IRQ resources before calling pcihpremovedevices().

Also modify the lifetime of the workqueue at struct pnvphpslot::wq so that it is only destroyed in pnvphpfreeslot(), instead of pnvphpdisableirq(). This is required since pnvphpdisableirq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated.

The abridged kernel panic that occurs without this patch is as follows:

WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msidevicedatarelease+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msidevicedatarelease+0x34/0x9c (unreliable) releasenodes+0x64/0x13c devresreleaseall+0xc0/0x140 devicedel+0x2d4/0x46c pcidestroydev+0x5c/0x194 pcihpremovedevices+0x90/0x128 pcihpremovedevices+0x44/0x128 pnvphpdisableslot+0x54/0xd4 powerwritefile+0xf8/0x18c pcislotattrstore+0x40/0x5c sysfskfwrite+0x64/0x78 kernfsfopwriteiter+0x1b0/0x290 vfswrite+0x3bc/0x50c ksyswrite+0x84/0x140 systemcallexception+0x124/0x230 systemcallvectoredcommon+0x15c/0x2ec

[bhelgaas: tidy comments]

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

Squashfs: check return result of sbminblocksize

Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfsbioread" bug.

Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOPSETBLOCKSIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfsfillsuper() fails.

---- msblk->devblksize = sbminblocksize(sb, SQUASHFSDEVBLKSIZE); msblk->devblksizelog2 = ffz(~msblk->devblksize); ----

sbminblocksize() returns 0, which means msblk->devblksize is set to 0.

As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksizelog2 is set to 64.

This subsequently causes the

UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')

This commit adds a check for a 0 return by sbminblocksize().

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

padata: avoid UAF for reorderwork

Although the previous patch can avoid ps and ps UAF for doserial, it can not avoid potential UAF issue for reorderwork. This issue can happen just as below:

cryptorequest cryptorequest cryptodelalg padatadoserial ... padatareorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }

padatadoserial // new request added listadd // sees the new request queuework(reorderwork) padatareorder queueworkon(squeue->work) ...

<kworker context> padataserialworker // completes new request, // no more outstanding // requests

cryptodelalg // free pd

<kworker context> invokepadatareorder // UAF of pd

To avoid UAF for 'reorderwork', get 'pd' ref before put 'reorderwork' into the 'serialwq' and put 'pd' ref until the 'serialwq' finish.

An Out-Of-Bounds Read vulnerability in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This flaw could allow a local attacker to crash the system or leak internal kernel information.

Refer; https://bugzilla.kernel.org/showbug.cgi?id=218218

[1] Retrieve WordCount and add offset2 to the data part of smb [2] Retrieve a 16-byte value from the calculated pointer

c unsigned int smbCalcSize(void buf) { struct smbhdr ptr = buf; return (sizeof(struct smbhdr) + (2 ptr->WordCount) + 2 / size of the bcc field / + getbcc(ptr)); } ... static inline u16 getbcc(struct smbhdr hdr) { le16 bcptr = (le16 )BCC(hdr);

return getunalignedle16(bcptr);//[2] } ... static inline void BCC(struct smbhdr smb) { return (void )smb + sizeof(smb) + 2 smb->WordCount; //[1] }

[2] cifsdemultiplexthread → standardreceive3 → cifshandlestandard → checkSMB → smbCalcSize

c int checkSMB(char buf, unsigned int totalread, struct TCPServerInfo server) { struct smbhdr smb = (struct smbhdr )buf; u32 rfclen = be32tocpu(smb->smbbuflength); u32 clclen; / calculated length / cifsdbg(FYI, "checkSMB Length: 0x%x, smbbuflength: 0x%x\n", totalread, rfclen);

/ is this frame too small to even get to a BCC? / if (totalread < 2 + sizeof(struct smbhdr)) { ... }

/ otherwise, there is enough to get to the BCC / if (checksmbhdr(smb)) return -EIO; clclen = smbCalcSize(smb);