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

KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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

fuse-uring: fix moving cancelled entry to entinuserspace list

fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.

Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.

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

fuse-uring: remove request-less entries from entwreqqueue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be terminated and fuseuringreqend() will set ent->fusereq to NULL but it will leave the entry on entwreqqueue in FRRSFUSEREQ state. This can lead to a NULL deref if the request expiration logic scans entwreqqueue in the window before the entry is moved off it.

Fix this by taking the entry off entwreqqueue and changing its state from FRRSFUSEREQ to FRRSINVALID before terminating the request.

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:

net: ethtool: phy: avoid NULL deref when PHY driver is unbound

phydev->drv can become NULL while the phydevice is still attached to its netdevice, namely after the PHY driver is unbound via sysfs:

echo <mdioid> > /sys/bus/mdiobus/drivers/<phydrv>/unbind

phyremove() clears phydev->drv but doesn't call phydetach(), so the phydevice stays in the link topology xarray and ethnlreqgetphydev() still hands it back. ETHTOOLMSGPHYGET then oopses on:

repdata->drvname = kstrdup(phydev->drv->name, GFPKERNEL);

drvname is already treated as optional by phyreplysize(), phyfillreply() and phycleanupdata(), so just skip the allocation when there is no driver bound.

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

igc: fix potential skb leak in igcfpexmitsmdframe()

When igcfpeinittxdescriptor() fails, no one takes care of an allocated skb, leaking it. [1] Use devkfreeskbany() on failure.

Tested on an I226 adapter with the following command, while injecting faults in igcfpeinittxdescriptor() to trigger the error path. # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on

[1] unreferenced object 0xffff888113c6cdc0 (size 224): ... backtrace (crc be3d3fda): kmemcacheallocnodenoprof+0x3b1/0x410 allocskb+0xde/0x830 igcfpexmitsmdframe.isra.0+0xad/0x1b0 igcfpesendmpacket+0x37/0x90 ethtoolmmsvverifytimer+0x15e/0x300

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

perf/x86/intel: Improve validation and configuration of ACR masks

Currently there are several issues on the user space ACR mask validation and configuration. - The validation for user space ACR mask (attr.config2) is incomplete, e.g., the ACR mask could include the index which belongs to another ACR events group, but it's not validated. - An early return on an invalid ACR mask caused all subsequent ACR groups to be skipped. - The stale hardware ACR mask (hw.config1) is not cleared before setting new hardware ACR mask.

The following changes address all of the above issues. - Figure out the event index group of an ACR group. Any bits in the user-space mask not present in the index group are now dropped. - Instead of an early return on invalid bits, drop only the invalid portions and continue iterating through all ACR events to ensure full configuration. - Explicitly clear the stale hardware ACR mask for each event prior to writing the new configuration.

Besides, a non-leader event member of ACR group could be disabled in theory. This could cause bit-shifting errors in the acrmask of remaining group members. But since ACR sampling requires all events to be active, this should not be a big concern in real use case. Add a "FIXME" comment to notice this risk.

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

drm/i915/dmc: Fix an unlikely NULL pointer deference at probe

inteldmcupdatedc6allowedcount() oopses when DMC hasn't been initialized, and dmc is thus NULL.

That would be the case when the call path is intelpowerdomainsinithw() -> {skl,bxt,icl}displaycoreinit() -> gen9setdcstate() -> inteldmcupdatedc6allowedcount(), as intelpowerdomainsinithw() is called before inteldmcinit().

However, gen9setdcstate() calls inteldmcupdatedc6allowedcount() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before.

It is also strange to have DC6 enabled at boot, since that would require the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and the driver stopping / reprogramming the firmware is a poorly specified sequence and as such unlikely an intentional BIOS behaviour. It's more likely that BIOS is leaving an unintentionally enabled DC6 HW state behind (without actually loading the required DMC firmware for this).

The tracking of the DC6 allowed counter only works if starting / stopping the counter depends on the SW DC6 state vs. the current HW DC6 state (since stopping the counter requires the DC5 counter captured when the counter was started). Thus, using the HW DC6 state is incorrect and it also leads to the above oops. Fix both issues by using the SW DC6 state for the tracking.

This is v2 of the fix originally sent by Jani, updated based on the first Link: discussion below.

(cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0)

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

drm/vmwgfx: Don't overwrite KMS surface dirty tracker

We were overwriting the surface's dirty tracker here causing a memory leak.

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

crypto: ccp - Fix dereferencing uninitialized error pointer

Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 sevplatforminitlocked() error: we previously assumed 'error' could be null

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

crypto: ccp - Always pass in an error pointer to sevplatformshutdownlocked()

When

9770b428b1a2 ("crypto: ccp - Move devinfo/err messages for SEV/SNP init and shutdown")

moved the error messages dumping so that they don't need to be issued by the callers, it missed the case where sevfirmwareshutdown() calls sevplatformshutdownlocked() with a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk:

#PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022 RIP: 0010:sevplatformshutdownlocked.cold+0x0/0x21 [ccp]

That rIP is:

00000000000006fd <sevplatformshutdownlocked.cold>: 6fd: 8b 13 mov (%rbx),%edx 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi 703: 89 c1 mov %eax,%ecx

Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e RSP: 0018:ffffc90005467d00 EFLAGS: 00010282 RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000 ^^^^^^^^^^^^^^^^ and %rbx is nice and clean.

Call Trace: <TASK> sevfirmwareshutdown.isra.0 sevdevdestroy pspdevdestroy spdestroy pcideviceshutdown deviceshutdown kernelpoweroff hibernate.cold statestore kernfsfopwriteiter vfswrite ksyswrite dosyscall64 entrySYSCALL64afterhwframe

Pass in a pointer to the function-local error var in the caller.

With that addressed, suspending the ccp shows the error properly at least:

ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110 SEV-SNP: Leaking PFN range 0x146800-0x146a00 SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00] ... ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0 ACPI: PM: Preparing to enter system sleep state S5 kvm: exiting hardware virtualization reboot: Power down

Btw, this driver is crying to be cleaned up to pass in a proper I/O struct which can be used to store information between the different functions, otherwise stuff like that will happen in the future again.

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

clk: spacemit: ccumix: fix inverted condition in ccumixtriggerfc()

Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling.

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

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

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

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

pNFS: Fix uninited ptr deref in block/scsi layout

The error occurs on the third attempt to encode extents. When function exttreepreparecommit() reallocates a larger buffer to retry encoding extents, the "layoutupdatepages" page array is initialized only after the retry loop. But exttreefreecommitdata() is called on every iteration and tries to put pages in the array, thus dereferencing uninitialized pointers.

An additional problem is that there is no limit on the maximum possible buffersize. When there are too many extents, the client may create a layoutcommit that is larger than the maximum possible RPC size accepted by the server.

During testing, we observed two typical scenarios. First, one memory page for extents is enough when we work with small files, append data to the end of the file, or preallocate extents before writing. But when we fill a new large file without preallocating, the number of extents can be huge, and counting the number of written extents in exttreeencodecommit() does not help much. Since this number increases even more between unlocking and locking of exttree, the reallocated buffer may not be large enough again and again.

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

KVM: x86: Do IRR scan in kvmapicupdateirr even if PIR is empty

Fall back to apicfindhighestvector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR.

In a nested VM stress test, the following WARNING fires in vmxchecknestedevents() when kvmcpuhasinterrupt() reports a pending interrupt but the subsequent kvmapichasinterrupt() (which invokes vmxsyncpirtoirr() again) returns -1:

WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmxchecknestedevents+0x6bf/0x6e0 [kvmintel] Call Trace: kvmcheckandinjectevents vcpuenterguest.constprop.0 vcpurun kvmarchvcpuioctlrun kvmvcpuioctl x64sysioctl dosyscall64 entrySYSCALL64afterhwframe

The root cause is a race between vmxsyncpirtoirr() on the target vCPU and vmxdeliverpostedinterrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction:

1. pitestandsetpir(vector) -- sets the PIR bit 2. pitestandseton() -- sets PID.ON

The following interleaving triggers the bug:

Sender vCPU (IPI): Target vCPU (1st syncpirtoirr): B1: set PIR[vector] A1: piclearon() A2: piharvestpir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct maxirr) B2: set PID.ON = 1

Target vCPU (2nd syncpirtoirr): C1: piteston() -> TRUE (from B2) C2: piclearon() -> ON=0 C3: piharvestpir() -> PIR empty C4: maxirr = -1, early return IRR NOT SCANNED

The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpuenterguest() iteration), but the incorrect maxirr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.

Bluetooth: fix memory leak in error path of hciallocdev()

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

wifi: cfg80211: enforce HE/EHT cap/oper consistency

Xiang Mei reports that mac80211 could crash if ehtcap is set but ehtoper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements.

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

iommu/amd: Bounds-check devid in rlookupamdiommu()

iommudeviceregister() walks every device on the PCI bus via busforeachdev() and calls amdiommuprobedevice() for each. The inlined checkdevice() path computes the device's sbdf, calls rlookupamdiommu() to find the owning IOMMU, and only afterwards verifies devid <= pciseg->lastbdf. rlookupamdiommu() indexes rlookuptable[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run.

This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irqlookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which checkdevice() then dereferences as a struct amdiommu , causing a boot-time GPF.

Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object:

pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amdiommuprobedevice+0x54/0x3a0 Call Trace: iommuprobedevice+0x107/0x520 probeiommugroup+0x29/0x50 busforeachdev+0x7e/0xe0 iommudeviceregister+0xc9/0x240 iommugotostate+0x9c0/0x1c60 amdiommuinit+0x14/0x40 pciiommuinit+0x16/0x60 dooneinitcall+0x47/0x2f0

Guard the array access in rlookupamdiommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.

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

iommu/dma: Do not try to iommumap a 0 length region in swiotlb

iommudmaiovalinkswiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommumap() with a 0 size which the iommupt implementation will fail as illegal.

It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARNON.

Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink.

This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition.

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

fuse: fix uninit-value in fusedentryrevalidate()

fusedentryrevalidate() may be called with a dentry that didn't had ->dtime initialised. The issue was found with KMSAN, where lookupopen() calls dalloc(), followed by drevalidate(), as shown below:

===================================================== BUG: KMSAN: uninit-value in fusedentryrevalidate+0x150/0x13d0 fs/fuse/dir.c:394 fusedentryrevalidate+0x150/0x13d0 fs/fuse/dir.c:394 drevalidate fs/namei.c:1030 [inline] lookupopen fs/namei.c:4405 [inline] openlastlookups fs/namei.c:4583 [inline] pathopenat+0x1614/0x64c0 fs/namei.c:4827 dofileopen+0x2aa/0x680 fs/namei.c:4859 [...]

Uninit was created at: slabpostallochook mm/slub.c:4466 [inline] slaballocnode mm/slub.c:4788 [inline] kmemcachealloclrunoprof+0x382/0x1280 mm/slub.c:4807 dalloc+0x55/0xa00 fs/dcache.c:1740 dallocparallel+0x99/0x2740 fs/dcache.c:2604 lookupopen fs/namei.c:4398 [inline] openlastlookups fs/namei.c:4583 [inline] pathopenat+0x135f/0x64c0 fs/namei.c:4827 dofileopen+0x2aa/0x680 fs/namei.c:4859 [...] =====================================================

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

drm/i915/vrr: Configure VRR timings after enabling TRANSDDIFUNCCTL

Apparently ICL may hang with an MCE if we write TRANSVRRVMAX/FLIPLINE before enabling TRANSDDIFUNCCTL.

Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason.

BSpec does tell us to configure VRR after enabling TRANSDDIFUNCCTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANSVRRCTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANSDDIFUNCCTL and TRANSVRRVMAX/VMIN/FLIPLINE, among other things

So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later.

BSpec: 22243 (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74)

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

afunix: Fix memleak of newsk in unixstreamconnect().

When preparepeercred() fails in unixstreamconnect(), unixreleasesock() is not called for newsk, and the memory is leaked.

Let's move preparepeercred() before unixcreate1().

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

ovpn: tcp - don't deref NULL sksocket member after tcpclose()

When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing.

This happens in: ovpnpeerkeepalivework() unlockovpn(releaselist)

This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks.

In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of:

tcpclose(sk) tcpclose(sk) sockorphan(sk) sksetsocket(sk, NULL)

The last function call will set sk->sksocket to NULL.

When the releasing routine is resumed, ovpntcpsocketdetach() will attempt to dereference sk->sksocket to restore its original ops member. This operation will crash due to sk->sksocket being NULL.

Fix this race condition by testing-and-accessing sk->sksocket atomically under sk->skcallbacklock.