The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev->cfgdesc, from the dedicated usbdeviceheap in usbhdevicesetconfiguration() (subsys/usb/host/usbhdevice.c). On three failure paths — a failed full-length GETDESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parseconfigurationdescriptor() — the buffer was released with kheapfree() but the pointer was left dangling. The cleanup in usbhdevicefree() is guarded only by if (udev->cfgdesc != NULL), so it frees the same block a second time.

The path is driven entirely by the attached peripheral: usbhdeviceconnect() calls usbhdeviceinit(), which ends in usbhdevicesetconfiguration(), and on failure usbhdeviceconnect() calls usbhdevicefree(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0–v4.3.x the second free instead arrives via devremovedhandler()/devconnectedhandler() in subsys/usb/host/usbhcore.c, so it requires a removal or duplicate-connect event after the failed enumeration — a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.

The result is a double free on usbdeviceheap. On builds where lib/heap hardening is active (the current default CONFIGSYSHEAPHARDENINGBASIC), sysheapfree() detects the already-free chunk and calls kpanic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection — earlier releases, or CONFIGSYSHEAPHARDENINGNONE — the second free manipulates a chunk already on the free list, corrupting the heap's free list so that later allocations can return overlapping or invalid blocks.

Exploitation beyond denial of service is bounded by the fact that usbdeviceheap is a small dedicated heap (CONFIGUSBHUSBDEVICEHEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIGUSBHOSTSTACK being marked experimental and disabled by default. The fix sets udev->cfgdesc = NULL after every kheapfree(), making the cleanup guard sound.

gptpmiqualifyannounce() in subsys/net/l2/ethernet/gptp/gptpmi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->stepsremoved (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because pathsequence is the flexible member of the wire TLV (struct gptppathtracetlv) and GPTPANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.

The stack's only length validation, GPTPANNOUNCECHECKLEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with stepsremoved = 254; the frame passes the length check and reception path (netgptprecv() → gptphandlemsg() → gptpmiqualifyannounce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer.

The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIGNETGPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.

The fix computes the true entry count as tlv.len / GPTPCLOCKIDLEN and rejects the announce when stepsremoved + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.

ASoC: rt700-sdw: always drain jack work on remove

drm/lima: call drmmminit() with a valid allocation range

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

platform/surface: acpi-notify: Check ACPI companion before use

Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of devicematchdriveroverride(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence.

sanprobe() dereferences the result of ACPICOMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPIHANDLE() to ACPICOMPANION().

Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPICOMPANION() against NULL during probe") does for the core ACPI platform drivers.

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

misc: bcm-vk: Use acquire/release for msgqinited

bcmvksyncmsgq() fills the message queue information and then sets msgqinited. Readers call bcmvkdrvaccessok() before accessing the message queues and their cached queue information.

atomicset()/atomicread() do not order those accesses. A reader can see msgqinited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate.

Keep the clear in bcmvkblkdrvaccess() as atomicset(). It closes the gate and does not publish queue state to readers.

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

mtd: part: reject MTDPARTOFSRETAIN in mtdaddpartition()

mtdaddpartition() does not reject the special offset value MTDPARTOFSRETAIN (-3), which leads to a WARNON in addmtddevice() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on curoffset being the end of the previous partition, but in the dynamic partition path curoffset equals the offset argument itself, causing undefined behavior.

Commit 5daa7b21496a ("mtd: prepare partition add and del functions for ioctl requests") introduced mtdaddpartition() and correctly rejected MTDPARTOFSAPPEND (-1) and MTDPARTOFSNXTBLK (-2), since those special offsets rely on curoffset tracking the previous partition's end. However, commit 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") later added MTDPARTOFSRETAIN (-3) for the static partition table path without updating mtdaddpartition() to also reject this value.

With offset=-3 passed via BLKPG, the RETAIN size calculation in allocatepartition() underflows (parentsize - 0xFFFFFFFFFFFFFFFD = parentsize + 3). If the underflow result does not appear to leave enough space, allocatepartition() jumps to outregister via goto, skipping erasesize initialization. This results in erasesize=0, which triggers:

WARNON((!mtd->erasesize || !master->erase) && !(mtd->flags & MTDNOERASE))

in addmtddevice(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the "out of reach" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error.

Fix this by adding MTDPARTOFSRETAIN to the rejection list in mtdaddpartition(), consistent with the existing handling of APPEND and NXTBLK.

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

RDMA/nldev: validate dynamic counter attribute length

RDMANLDEVATTRSTATHWCOUNTERS is a nested attribute whose children are consumed directly with nlagetu32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child.

Require every child payload to be exactly one u32 before reading it.

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

lib/testhmm: fail dmirrorfault() when the mirrored mm is gone

dmirrorfault() is called from the dmirrorread() and dmirrorwrite() retry loops after dmirrordoread() or dmirrordowrite() finds a missing device page table entry.

If the mirrored mm has already exited, mmgetnotzero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress.

Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.

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

wifi: mt76: mt7915: release hif2 reference on probe IRQ failure

The hif2 reference obtained by mt7915pciinithif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pciallocirqvectors() or the primary devmrequestirq() fails, the reference leaks. Drop it explicitly on those paths via mt7915puthif2().

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

scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path

qla2x00sysfsreadvpd() called ha->ispops->readoptrom() a second time after releasing optrommutex. The repeated read is redundant and, unlike the first, runs without optrommutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.

firmwareloader: do not queue completed sysfs fallback requests

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

phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend

There is a small window where the runtime suspend callback may run after pmruntimeenable() and before pmruntimeforbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: if (!qmp->phy->initcount) {

This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized.

Similarly to other qcom phy drivers, introduce a qmp->phyinitialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.

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

phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend

Runtime PM must be enabled before creating the PHY, since phycreate() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference.

Take a runtime PM usage reference with pmruntimegetnoresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur.

Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.

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

RDMA/cma: Fix WARNING in restort

syzbot reported a WARNON(!res->dev) in restort() triggered via addrhandler() during asynchronous address resolution:

" WARNING: drivers/infiniband/core/restrack.c:138 at restort+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ibaddr processonereq RIP: 0010:restort+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: <TASK> rdmarestrackadd+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addrhandler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 processonereq+0x2eb/0x540 drivers/infiniband/core/addr.c:624 processonework kernel/workqueue.c:3375 [inline] processscheduledworks+0xc4e/0x1630 kernel/workqueue.c:3458 workerthread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 retfromfork+0x514/0xb70 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK> "

In addrhandler(), cmaacquiredevbysrcip() is called to populate idpriv->cmadev and bind the associated ibdevice to idpriv->id.device. If cmaacquiredevbysrcip() returns an error (non-zero status), the ID remains unassociated with any RDMA device.

Previously, rdmarestrackadd(&idpriv->res) was invoked unconditionally even when cmaacquiredevbysrcip() failed, passing a resource with a NULL dev pointer and triggering the WARNON assertion in restort().

Fix this by only adding the resource to restrack when acquiring the device succeeds.

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

scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers

basereleasememorypools() unconditionally frees every ioc->pciesglookup[] entry, including ones the setup loop never allocated after a partial failure, causing a "bad dma" warning on debug kernels or a NULL pointer dereference otherwise.

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

nullblk: serialize configfs attribute updates with device setup

The attribute store methods generated with NULLBDEVICEATTR() refuse to change the configuration of a live device by testing NULLBDEVFLCONFIGURED, but that flag is only set by nullbdevicepowerstore() after nulladddev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with nulladddev() and change the device configuration while it is being used.

nulladddev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources:

CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullbdevicepowerstore() mutexlock(&lock) nulladddev() if (dev->zoned) -> false / no BLKFEATZONED / nullbdevicezonedstore() testbit(FLCONFIGURED) -> 0 dev->zoned = true blkmqallocdisk() / queue is not zoned / if (nullb->dev->zoned) -> true nullregisterzoneddev() blkrevalidatediskzones()

blkrevalidatediskzones() is then called for a queue that does not have BLKFEATZONED set, which triggers its WARNONONCE() and fails the device setup with -EIO:

WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blkrevalidatediskzones+0x4c/0x560

Clearing dev->zoned in the same window is worse: the queue is created with BLKFEATZONED but the zone resources are never initialized, so adddisk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which nullprocesszonedcmd() dereferences on the first write.

Fix this by taking the global lock, which nullbdevicepowerstore() already holds across nulladddev() and nulldeldev(), around both the NULLBDEVFLCONFIGURED test and the update of the device configuration. The submitqueues and pollqueues apply callbacks are now called with that lock held, so remove the locking they did themselves.

Since the store methods can run as soon as configfsregistersubsystem() returns, that is, before nullinit() gets to mutexinit(&lock), also initialize the lock statically with DEFINEMUTEX().

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

smb: server: fix leak of ksmbdipcloginrequestext() returned buffer

Free it unconditionally after ksmbdallocuser() calls.

kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm "pool-0", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): kvmallocnodenoprof+0x730/0x920 handlegenericevent+0xec/0x1a0 [ksmbd] genlfamilyrcvmsgdoit+0xe0/0x130 genlrcvmsg+0x181/0x290 netlinkrcvskb+0x4f/0x100 genlrcv+0x28/0x40 netlinkunicast+0x1e6/0x2c0 netlinksendmsg+0x20a/0x450 syssendmsg+0x2e8/0x310 syssendmsg+0x78/0xc0 syssendmsg+0x63/0xc0 dosyscall64+0xa1/0x670 entrySYSCALL64afterhwframe+0x76/0x7e

drm/amd/display: fix division by zero in getestimatedbw()

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

USB: gadget: fix NULL pointer dereference in gadgetdevioctl()

gadgetdevioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl.

Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.

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

xhci: fix lost bounce buffers on TDs spanning several ring segments

When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhcialigntd() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhciunmaptdbouncebuffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer.

The enqueue path records the segment that was bounced in td->bounceseg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounceseg, so every earlier bounce buffer is neither copied back nor DMA unmapped.

The URB still completes with actuallength equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce.

Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verityprefetchio() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted:

device-mapper: verity: 8:2: metadata block 10850 is corrupted

A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity

The bounce state (bouncebuf, bouncedma, bouncelen, bounceoffs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounceseg and, on completion, walk the segments from td->startseg up to it, unmapping every segment that still has a pending bounce.

Stopping at td->bounceseg rather than td->endseg matters: a bounce implies the TD continues past that segment's link TRB, so bounceseg is always strictly before endseg, and a later TD may already have started in endseg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that endseg == startseg.

[mn: Add ring->numsegs check to prevent unlikely infinite for loop.]

i2c: mux: Fix channel node leak on adapter add failure

ASoC: cs35l33: drain threaded IRQ before runtime suspend

ASoC: cs35l34: drain threaded IRQ before runtime suspend

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

media: airspy: use vb2videounregisterdevice() on disconnect to fix NULL deref

airspydisconnect() clears s->udev under v4l2lock, but airspystopstreaming() unconditionally calls airspyctrlmsg() and airspyfreestreambufs() afterwards. If a streaming user closes the device after disconnect, stopstreaming() runs and dereferences the NULL s->udev:

airspystopstreaming() airspyctrlmsg(s, CMDRECEIVERMODE, 0, 0, NULL, 0) usbsndctrlpipe(s->udev, 0) / NULL deref / airspyfreestreambufs(s) usbfreecoherent(s->udev, ...) / NULL deref /

The airspy driver uses vb2foprelease() in its fileoperations, so replace videounregisterdevice(&s->vdev) with vb2videounregisterdevice(&s->vdev) and move it before clearing s->udev. vb2videounregisterdevice() releases the vb2 queue, which synchronously runs airspystopstreaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid.

vb2videounregisterdevice() locks vdev->queue->lock (vbqueuelock) internally, and stopstreaming() locks v4l2lock, so the previous outer mutexlock(&s->vbqueuelock) / mutexlock(&s->v4l2lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state.

Issue identified by automated review of the INV-003 series at https://sashiko.dev/

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

media: cedrus: fix memory leak in cedrusinitctrls()

In cedrusinitctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak.

Fix this by calling v4l2ctrlhandlerfree() on the ctx->ctrls allocation failure path.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1.

An x8664 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.

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

scsi: qla2xxx: Don't query firmware state while chip is down

qla2x00fwstateshow() initializes rval to QLAFUNCTIONFAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00getfirmwarestate() because rval != QLASUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrommutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt.

Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrommutex, and only when the chip is up and not EEH-busy.

drm/amd/display: avoid divide-by-zero in islutlinear()

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

mm/damon/core: avoid infinite kdamondmergeregions() internal loop

Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1.

Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those.

This patch (of 6):

Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamondmergeregions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged.

The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If maxthres is larger than UINTMAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely.

Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold.

This issue is unlikely to occur in real world, since having the maxthres higher than UINTMAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple.

The issue was discovered [1] by Sashiko.

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

SUNRPC: check rpcsockaddr2uaddr() return value in rpcbregisterinet4/6

rpcbregisterinet4() and rpcbregisterinet6() store the result of rpcsockaddr2uaddr() into map->raddr without checking it for NULL. rpcsockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROCSET encode path: rpcbregistercall() -> rpccallsync() -> rpcbencgetaddr() -> encoderpcbstring(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel.

The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encoderpcbstring (net/sunrpc/rpcbclnt.c:890) rpcbencgetaddr (net/sunrpc/rpcbclnt.c:910) rpcauthwrapreqencode (net/sunrpc/auth.c:745) callencode (net/sunrpc/clnt.c:1966) rpcexecute (net/sunrpc/sched.c:952) rpcruntask (net/sunrpc/clnt.c:1243) rpccallsync (net/sunrpc/clnt.c:1272) rpcbv4register (net/sunrpc/rpcbclnt.c:500) svcgenericrpcbindset nfsdrpcbindset svcregister svcsetupsocket svcaddsock writeports nfsctltransactionwrite vfswrite

The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFPKERNEL kstrdup() in rpcsockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check.

Mirror that handling: bail out with -ENOMEM when rpcsockaddr2uaddr() returns NULL, before the address is fed into the encoder.