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

ksmbd: fix SID memory leak in setposixaclentriesdacl() on overflow

Commit 299f962c0b02 ("ksmbd: use checkaddoverflow() to prevent u16 DACL size overflow") added checkaddoverflow() guards that break out of the ACE-building loops in setposixaclentriesdacl() when the accumulated DACL size would wrap past 65535.

However, each iteration allocates a struct smbsid via kmallocobj() at the top of the loop and relies on the kfree(sid) call at the end of the loop body (the 'passsamesid' label in the first loop, and the explicit kfree at the tail of the second loop) to release it. The newly introduced 'break' statements bypass those kfree() calls, leaking the sid buffer every time an overflow is detected.

A malicious or malformed file with enough POSIX ACL entries to trip the overflow check will leak one or more struct smbsid allocations on every request that touches the file's DACL, providing a trivial kernel memory exhaustion vector.

Free sid before breaking out of the loops to plug the leak.

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

platform/x86: uniwill-laptop: Do not enable the charging limit even when forced

It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices.

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

Bluetooth: btmtk: fix urb->setuppacket leak in error paths

The setuppacket of control urb is not freed if usbsubmiturb fails or the submitted urb is killed. Add free in these two paths.

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

erofs: fix metabuf leak in inode xattr initialization

commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofsbuf instances. erofsinitinodexattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.

Some error paths after erofsreadmetabuf() leave through outunlock without dropping the metabuf, so the folio reference can leak.

Consolidate the cleanup at outunlock. erofsputmetabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFSIBLXATTRBIT covered by a single cleanup site.

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

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

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

dma-mapping: move dmamapresource() sanity check into debug code

dmamapresource() uses pfnvalid() to ensure the range is not RAM. However, pfnvalid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. On ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that share a section with RAM will falsely trigger the WARNONONCE and cause dmamapresource() to return DMAMAPPINGERROR.

This causes a WARNING on Raspberry Pi 4 during spibcm2835 probe because the SPI FIFO register (0xfe204004) falls in the same sparsemem section as the end of RAM (0xf8000000-0xfbffffff), both in section 31 (0xf8000000-0xffffffff).

Move the sanity check from dmamapresource() into debugdmamapphys() and replace the unreliable pfnvalid() with pfnvalid() && !PageReserved(), which correctly identifies actual usable RAM without false positives for MMIO regions that happen to have struct pages.

Since dmamapresource() is dmamapphys(DMAATTRMMIO), the check applies equally to both APIs. Any non-reserved page represents kernel memory to a sufficient degree that using DMAATTRMMIO on it is almost certainly wrong and risks breaking coherency on non-coherent platforms. ZONEDEVICE pages used for PCI P2P DMA (MEMORYDEVICEPCIP2PDMA) have PageReserved set, so they will not trigger a false positive.

The check no longer blocks the mapping and uses errprintk() to integrate with dma-debug filtering.

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

drm/msm/adreno: Fix a reference leak in a6xxgpuinit()

In a6xxgpuinit(), node is obtained via ofparsephandle(). While there was a manual ofnodeput() at the end of the common path, several early error returns would bypass this call, resulting in a reference leak. Fix this by using the free(devicenode) cleanup handler to release the reference when the variable goes out of scope.

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

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

media: rc: igorplugusb: fix control request setup packet

Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules.

However, the driver still passes &ir->request to usbfillcontrolurb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usbctrlrequest.

USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot:

usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0

Pass ir->request itself as the setup packet.

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

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]

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

net: ti: icssm-prueth: fix ethportsnode leak in probe

The error path on ofpropertyreadu32() failure inside icssmpruethprobe() returns without putting ethportsnode, which was acquired before the foreachchildofnode() loop.

Drop it before returning.

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

btrfs: tracepoints: fix sleep while in atomic context in btrfssyncfile()

The trace event btrfssyncfile() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dgetparent(), can sleep, triggering a kernel splat.

This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following:

[53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 32773, name: xfsio [53.988] preemptcount: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfsio Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] <TASK> [54.076] dumpstacklvl+0x56/0x80 [54.079] mightresched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] traceeventraweventbtrfssyncfile+0x75/0x140 [btrfs] [54.089] btrfssyncfile+0x1ed/0x530 [btrfs] [54.087] ? handlemmfault+0x8ae/0xed0 [54.089] btrfsdowriteiter+0x172/0x210 [btrfs] [54.091] vfswrite+0x21f/0x450 [54.094] x64syspwrite64+0x8d/0xc0 [54.096] ? douseraddrfault+0x20c/0x670 [54.099] dosyscall64+0x60/0xf20 [54.092] ? clearbhbloop+0x60/0xb0 [54.094] entrySYSCALL64afterhwframe+0x76/0x7e

So stop using dgetparent() and dput() and access the parent dentry directly as dentry->dparent. This is also what ext4 is doing in its equivalent trace event ext4syncfileenter().

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

testkprobes: clear kprobes between test runs

Running the kprobes sanity tests twice makes all tests fail and eventually crashes the kernel.

[root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobestest/run ... # Totals: pass:5 fail:0 skip:0 total:5 ok 1 kprobestest [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobestest/run ... # testkprobe: EXPECTATION FAILED at lib/tests/testkprobes.c:64 Expected 0 == registerkprobe(&kp), but registerkprobe(&kp) == -22 (0xffffffffffffffea) ... Unable to handle kernel paging request ...

The testsuite defines several kprobes and kretprobes as static variables that are preserved across test runs.

After registerkprobe and unregisterkprobe, a kprobe contains some leftover data that must be cleared before the kprobe can be registered again. The tests are setting symbolname to define the probe location. Address and flags must be cleared.

The existing code clears some of the probes between subsequent tests, but not between two test runs. The leftover data from a previous test run makes the registrations fail in the next run.

Move the cleanups for all kprobes into kprobestestinit, this function is called before each single test (including the first test of a test run).

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

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR

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

wifi: cfg80211: advance loop vars in cfg80211mergeprofile()

cfg80211mergeprofile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls

cfg80211getprofilecontinuation(ie, ielen, mbssidelem, subelem)

but never advances mbssidelem or subelem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same nextmbssid; and the same nextsub bytes are memcpy()'d into mergedie at a growing offset until the buffer fills.

Advance both mbssidelem and subelem to the just-consumed continuation so the next call to cfg80211getprofilecontinuation() searches for a further continuation beyond it (or returns NULL when none exists).

A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211mergeprofile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.

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

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

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

i2c: tegra: fix pmruntime leak on mutexlock failure

If tegrai2cmutexlock() fails, the function returns without calling pmruntimeput(), leaking the runtime PM reference acquired by the preceding pmruntimegetsync(). This prevents the device from ever entering runtime suspend.

Add the missing pmruntimeput() before returning on lock failure.

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

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: ep93xx: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

kho: skip KHO for crash kernel

khofillkimage() unconditionally populates the kimage with KHO metadata for every kexec image type. When the image is a crash kernel, this can be problematic as the crash kernel can run in a small reserved region and the KHO scratch areas can sit outside it. The crash kernel then faults during khomemoryinit() when it tries phystovirt() on the KHO FDT address:

Unable to handle kernel paging request at virtual address xxxxxxxx ... fdtoffsetptr+... fdtchecknodeoffset+... fdtfirstpropertyoffset+... fdtgetpropertynamelen+... fdtgetprop+... khomemoryinit+... mmcoreinit+... startkernel+...

kholocatememhole() already skips KHO logic for KEXECTYPECRASH images, but khofillkimage() was missing the same guard. As khofillkimage() is the single point that populates image->kho.fdt and image->kho.scratch, fixing it here is sufficient for both arm64 and x86 as the FDT and bootparams path are bailing out when these fields are unset.

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

firmware: armffa: Check for NULL FF-A ID table while driver registration

The bus match callback assumes that every FF-A driver provides an idtable and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match.

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

ARM: integrator: Fix early initialization

Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcpinitearly calls sysconregmaplookupbycompatible which in turn calls ofsysconregister. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows.

Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at kmalloccachenoprof+0xec/0x39c LR is at kmalloccachenoprof+0x34/0x39c ... Call trace: kmalloccachenoprof from ofsysconregister+0x7c/0x310 ofsysconregister from devicenodegetregmap+0xa4/0xb0 devicenodegetregmap from intcpinitearly+0xc/0x40 intcpinitearly from startkernel+0x60/0x688 startkernel from 0x0

The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to sysconregmaplookupbycompatible returns -ENOMEM, and schedclockregister is never called.

Fix the problem by moving the early initialization code into the standard machine initialization code.

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

netfs, afs: Fix write skipping in dir/link writepages

Fix netfswritesingle() and afssinglewritepages() to better handle a write that would be skipped due to lock contention and WBSYNCNONE by returning 1 from netfswritesingle() if it skipped and making afssinglewritepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark.

This is really only theoretical for directories in netfswritesingle() as the only path to that is through afssinglewritepages() that takes the ->validatelock around it, thereby serialising it.

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

l2tp: use listdelrcu in l2tpsessionunhash

An unprivileged local user can pin a host CPU indefinitely in l2tpsessiongetbyifname() by issuing L2TPCMDSESSIONGET on L2TPATTRIFNAME concurrently with L2TPCMDSESSIONCREATE and L2TPCMDSESSIONDELETE on the same tunnel. All three commands take GENLUNSADMINPERM, so CAPNETADMIN in the netns user namespace suffices; on any host that has l2tpcore loaded the trigger is reachable from a standard unshare -Urn sandbox.

l2tpsessionunhash() removes a session from tunnel->sessionlist with listdelinit(), but that list is walked by l2tpsessiongetbyifname() with listforeachentryrcu() under rcureadlockbh(). listdelinit() leaves the deleted entry's next/prev self-pointing; a reader that has loaded the entry and then advances pos->list.next reads &session->list, containerof()s back to the same session, and listforeachentryrcu() never reaches the list head. The CPU stays in strcmp() inside the walker, with BH and preemption disabled, so RCU grace periods on the host stall behind it and the wedged thread cannot be killed (SIGKILL is delivered on syscall return).

Use listdelrcu() to match the existing listaddrcu() in l2tpsessionregister(); the deleted session remains visible to in-flight walkers with consistent next/prev pointers until kfreercu() in l2tpsessionfree() releases it. tunnel->sessionlist has exactly one listdelinit() call site; the listdelinit (&session->clist) at l2tpcore.c:533 operates on the per-collision list, which is not walked under RCU. listempty(&session->list) is not used anywhere in net/l2tp/ after the unhash point, so dropping the post-delete self-init is safe; the fix has no userspace-visible behavior change.

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

net: ethtool: fix NULL pointer dereference in phyreplysize

In phypreparedata(), several strings such as 'name', 'drvname', 'upstreamsfpname', and 'downstreamsfpname' are allocated using kstrdup(). However, these allocations were not checked for failure.

If kstrdup() fails for 'name', it returns NULL while the function continues. This leads to a kernel NULL pointer dereference and panic later in phyreplysize() when it unconditionally calls strlen() on the NULL pointer.

While other strings like 'upstreamsfpname' might be checked before access in certain code paths, failing to handle these allocations consistently can lead to incomplete data reporting or hidden bugs.

Fix this by adding proper NULL checks for all kstrdup() calls in phypreparedata() and implement a centralized error handling path using goto labels to ensure all previously allocated resources are freed on failure.

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

Bluetooth: L2CAP: ecredreconfigure: send packed pdu, not stack pointer

Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2capecredreconfigure() from an explicit packed struct to DEFINERAWFLEX(), but did not adjust the size and source-pointer arguments to l2capsendcmd():

- struct { - struct l2capecredreconfreq req; - le16 scid; - } pdu; + DEFINERAWFLEX(struct l2capecredreconfreq, pdu, scid, 1); ... l2capsendcmd(conn, chan->ident, L2CAPECREDRECONFREQ, sizeof(pdu), &pdu);

After the conversion, DEFINERAWFLEX() expands to declare an anonymous union pduu plus a local pointer "pdu" pointing at it. Therefore:

- sizeof(pdu) is now sizeof(struct l2capecredreconfreq ) = 8 on 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]). - &pdu is the address of the local pointer's stack storage, not the address of the request payload.

l2capsendcmd() forwards (data, count) to l2capbuildcmd(), which calls skbputdata(skb, data, count). The L2CAPECREDRECONFIGUREREQ packet body therefore contains 8 bytes copied from the kernel stack starting at &pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel stack address to the paired Bluetooth peer. The intended (mtu, mps, scid) fields are not transmitted at all, so the peer rejects the request as malformed and the L2CAPECREDRECONFIGURE feature itself has been broken for the local-side initiator since the introducing commit landed.

The sibling site l2capecredconnreq() in the same commit was converted correctly (sizeof(pdu) + len, pdu); only this site was missed.

Restore the original semantics: pass the full flex-struct size via structsize(pdu, scid, 1) and the pdu pointer (the struct address) as the source.

Validated on a stock 7.0-based host kernel via the real call path: setsockopt(SOLBLUETOOTH, BTRCVMTU, ...) on a BTCONNECTED L2CAPMODEEXTFLOWCTL socket emits an L2CAPECREDRECONFIGUREREQ whose body is 8 bytes (the on-stack pdu local's value) rather than the expected 6. Three captures from fresh socket / fresh hciemu peer on the same host -- low bytes vary per call, high 0xffff confirms a kernel virtual address (KASLR-randomised stack slot, not a fixed string):

RECONFREQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff RECONFREQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff RECONFREQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff

After this patch the body is 6 bytes carrying the expected little-endian (mtu, mps, scid).

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

Bluetooth: ISO: drop ISOEND frames received without prior ISOSTART

ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISOCONT branch of isorecv() guards against a missing ISOSTART by checking conn->rxlen before touching conn->rxskb, but ISOEND does not.

If a peer sends an ISOEND as the first packet on a fresh ISO connection, conn->rxskb is still NULL and conn->rxlen is zero, so skbput(conn->rxskb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this.

Mirror the ISOCONT check at the top of ISOEND so a stray end fragment is logged and dropped instead of crashing the host.