OESA-2026-2675

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/i915/gt: Fix timeline left held on VMA alloc error

The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform:

<4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drmWARNON(devpriv->mm.shrinkcount) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915gem.c:1309 i915gemcleanupearly+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915gemcleanupearly+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915driverlaterelease+0x2b/0xa0 [i915] <4> [239.331202] i915driverrelease+0x86/0xa0 [i915] <4> [239.331482] devmdrmdevinitrelease+0x61/0x90 <4> [239.331494] devmactionrelease+0x15/0x30 <4> [239.331504] releasenodes+0x3d/0x120 <4> [239.331517] devresreleaseall+0x96/0xd0 <4> [239.331533] deviceunbindcleanup+0x12/0x80 <4> [239.331543] devicereleasedriverinternal+0x23a/0x280 <4> [239.331550] ? busfinddevice+0xa5/0xe0 <4> [239.331563] devicedriverdetach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]---

If the test also unloads the i915 module then that's followed with:

<3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmemcacheshutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915vmainstance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915vmainstance+0xee/0xc10 [i915] <4> [357.789290] initstatuspage+0x7b/0x420 [i915] <4> [357.789532] intelenginesinit+0x1d8/0x980 [i915] <4> [357.789772] intelgtinit+0x175/0x450 [i915] <4> [357.790014] i915geminit+0x113/0x340 [i915] <4> [357.790281] i915driverprobe+0x847/0xed0 [i915] <4> [357.790504] i915pciprobe+0xe6/0x220 [i915] ...

Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@apiintelallocator@fork-simple-stress-signal, - igt@apiintelallocator@two-level-inception-interruptible, - igt@gemlinearblits@interruptible, - igt@primemmapcoherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt.

All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRMIOCTLI915GEMEXECBUFFER2, and ringcontextalloc(), specific to ring submission, in particular.

If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error.

In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915vmainstance() called from inside is interrupted with a signal, then ringcontextalloc() fails, leaving the timeline held referenced. On next I915GEMEXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind.

Get the legacy timeline only after successful allocation of the context engine's VMA.

v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.

(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)

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

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file.

For example, on Fedora, after booting the kernel with "imaappraise=fix evm=fix imapolicy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated,

# getfattr -m - -d -e hex /usr/bin/bash
# file: usr/bin/bash
security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.

Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,

#include <stdio.h>
#include <sys/xattr.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>

int main() {
    const char* file_path = "/usr/sbin/test_binary";
    const char* hex_string = "030204d33204490066306402304";
    int length = strlen(hex_string);
    char* ima_attr_value;
    int fd;

    fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
    if (fd == -1) {
        perror("Error opening file");
        return 1;
    }

    ima_attr_value = (char*)malloc(length / 2 );
    for (int i = 0, j = 0; i < length; i += 2, j++) {
        sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
    }

    if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
        perror("Error setting extended attribute");
        close(fd);
        return 1;
    }

    const char* selinux_value= "system_u:object_r:bin_t:s0";
    if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
        perror("Error setting extended attribute");
        close(fd);
        return 1;
    }

    close(fd);

    return 0;
}(CVE-2025-68183)

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

crash: fix crashkernel resource shrink

When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues:

1. Invalid crashkernel resource objects
2. Kernel crash if crashkernel shrinking is done twice

For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as:

cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel

If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexeccrashsize), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel

Instead, it should show 50MB: af000000-b21fffff : Crash kernel

Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86):

BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2f0 ? searchmoduleextables+0x19/0x60 ? searchbpfextables+0x5f/0x80 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? __releaseresource+0xd/0xb0 releaseresource+0x26/0x40 __crashshrinkmemory+0xe5/0x110 crashshrinkmemory+0x12a/0x190 kexeccrashsizestore+0x41/0x80 kernfsfopwriteiter+0x141/0x1f0 vfswrite+0x294/0x460 ksyswrite+0x6d/0xf0 <snip...>

This happens because __crashshrinkmemory()/kernel/crashcore.c incorrectly updates the crashkres resource object even when crashklowres should be updated.

Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.(CVE-2025-68198)

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

ipvs: fix ipv4 null-ptr-deref in route error path

The IPv4 code path in _ipvsgetoutrt() calls dstlinkfailure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fibcomputespecdst() when ipv4linkfailure() attempts to send ICMP destination unreachable messages.

The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4linkfailure") started calling _ipoptionscompile() from ipv4linkfailure(). This code path eventually calls fibcomputespecdst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4linkfailure"), but it only addressed the immediate devnet(skb->dev) dereference by using a fallback device. The fix was incomplete because fibcomputespecdst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dstlinkfailure().

The crash occurs when: 1. IPVS processes a packet in NAT mode with a misconfigured destination 2. Route lookup fails in __ipvsget_outrt() before establishing a route 3. The error path calls dstlinkfailure(skb) with skb->dev == NULL 4. ipv4linkfailure() → ipv4senddestunreach() → __ipoptionscompile() → fibcomputespecdst() 5. fibcomputespecdst() dereferences NULL skb->dev

Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skbdst(skb)->dev before calling dstlink_failure().

KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__indevget_rcu include/linux/inetdevice.h:233 RIP: 0010:fibcomputespecdst+0x17a/0x9f0 net/ipv4/fibfrontend.c:285 Call Trace: <TASK> specdstfill net/ipv4/ipoptions.c:232 specdstfill net/ipv4/ipoptions.c:229 __ipoptionscompile+0x13a1/0x17d0 net/ipv4/ipoptions.c:330 ipv4senddestunreach net/ipv4/route.c:1252 ipv4linkfailure+0x702/0xb80 net/ipv4/route.c:1265 dstlinkfailure include/net/dst.h:437 _ipvsgetoutrt+0x15fd/0x19e0 net/netfilter/ipvs/ipvsxmit.c:412 ipvsnatxmit+0x1d8/0xc80 net/netfilter/ipvs/ipvsxmit.c:764(CVE-2025-68813)

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

ipv6: BUG() in pskbexpandhead() as part of calipsoskbuffsetattr()

There exists a kernel oops caused by a BUGON(nhead < 0) at net/core/skbuff.c:2232 in pskbexpandhead(). This bug is triggered as part of the calipsoskbuffsetattr() routine when skbcow() is passed headroom > INTMAX (i.e. (int)(skbheadroom(skb) + len_delta) < 0).

The root cause of the bug is due to an implicit integer cast in _skbcow(). The check (headroom > skbheadroom(skb)) is meant to ensure that delta = headroom - skbheadroom(skb) is never negative, otherwise we will trigger a BUGON in pskbexpandhead(). However, if headroom > INTMAX and delta <= -NETSKBPAD, the check passes, delta becomes negative, and pskbexpandhead() is passed a negative value for nhead.

Fix the trigger condition in calipsoskbuffsetattr(). Avoid passing "negative" headroom sizes to skbcow() within calipsoskbuffsetattr() by only using skbcow() to grow headroom.

PoC: Using netlabelctl tool:

    netlabelctl map del default
    netlabelctl calipso add pass doi:7
    netlabelctl map add default address:0::1/128 protocol:calipso,7

    Then run the following PoC:

    int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);

    // setup msghdr
    int cmsg_size = 2;
    int cmsg_len = 0x60;
    struct msghdr msg;
    struct sockaddr_in6 dest_addr;
    struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,
                    sizeof(struct cmsghdr) + cmsg_len);
    msg.msg_name = &dest_addr;
    msg.msg_namelen = sizeof(dest_addr);
    msg.msg_iov = NULL;
    msg.msg_iovlen = 0;
    msg.msg_control = cmsg;
    msg.msg_controllen = cmsg_len;
    msg.msg_flags = 0;

    // setup sockaddr
    dest_addr.sin6_family = AF_INET6;
    dest_addr.sin6_port = htons(31337);
    dest_addr.sin6_flowinfo = htonl(31337);
    dest_addr.sin6_addr = in6addr_loopback;
    dest_addr.sin6_scope_id = 31337;

    // setup cmsghdr
    cmsg->cmsg_len = cmsg_len;
    cmsg->cmsg_level = IPPROTO_IPV6;
    cmsg->cmsg_type = IPV6_HOPOPTS;
    char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);
    hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80

    sendmsg(fd, &msg, 0);(CVE-2025-71085)

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

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

usbip: validate numberofpackets in usbippackret_submit()

When a USB/IP client receives a RETSUBMIT response, usbippackretsubmit() unconditionally overwrites urb->numberofpackets from the network PDU. This value is subsequently used as the loop bound in usbiprecviso() and usbippadiso() to iterate over urb->isoframedesc[], a flexible array whose size was fixed at URB allocation time based on the original numberofpackets from the CMD_SUBMIT.

A malicious USB/IP server can set numberofpackets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbiprecviso() writes to urb->isoframedesc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbiprecviso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stubrx.c) and gadget side (vudcrx.c) already validate numberofpackets in the CMDSUBMIT path since commits c6688ef9f297 ("usbip: fix stubrx: harden CMDSUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudcrx: harden CMDSUBMIT path to handle malicious input"). The server side validates against USBIPMAXISOPACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original numberofpackets.

This mirrors the existing validation of actuallength against transferbufferlength in usbiprecv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbiprecviso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbippackretsubmit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIPMAXISOPACKETS limit.

Fix this by checking rpdu->numberofpackets against urb->numberofpackets in usbippackretsubmit() before the overwrite. On violation, clamp to zero so that usbiprecviso() and usbippad_iso() safely return early.(CVE-2026-31607)

In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)

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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.(CVE-2026-43024)

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

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLV_HAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

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

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentryhashtable when user sets 'dhashentries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:dlookup+0x56/0x120 Call Trace: dlookup.cold+0x16/0x5d lookupdcache+0x27/0xf0 lookuponeqstrexcl+0x2a/0x180 startdirop+0x55/0xa0 simplestartcreating+0x8d/0xa0 debugfsstartcreating+0x8c/0x180 debugfscreatedir+0x1d/0x1c0 pinctrlinit+0x6d/0x140 dooneinitcall+0x6d/0x3d0 kernelinitfreeable+0x39f/0x460 kernelinit+0x2a/0x260

There will be only one bucket in dentryhashtable when dhashentries is set as one, and dhashshift is calculated as 32 by dcacheinit(). Then, following process will access more than one buckets(which memory region is not allocated) in dentryhashtable: dlookup b = dhash(hash) dentryhashtable + ((u32)hashlen >> dhashshift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> dhashshift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlistblforeachentryrcu(b) hlistblfirst_rcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentryhashtable bucket to two, so that 'dhash_shift' won't exceeds the bit width of type u32.(CVE-2026-43071)

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

net: afkey: zero aligned sockaddr tail in PFKEY exports

PF_KEY export paths use pfkey_sockaddr_size() when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, pfkey_sockaddr_fill() initializes only the first 28 bytes of struct sockaddr_in6, leaving the final 4 aligned bytes uninitialized.

Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain skb_put():

• SADB_ACQUIRE
• SADB_X_NAT_T_NEW_MAPPING
• SADB_X_MIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkey_sockaddr_fill().(CVE-2026-43088)

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

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.(CVE-2026-43089)

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmget_ae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.(CVE-2026-43107)

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

tcp: fix potential race in tcpv6synrecvsock()

Code in tcpv6synrecvsock() after the call to tcpv4synrecvsock() is done too late.

After tcpv4synrecvsock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcpv6mappedchildinit() and call this new helper from tcpv4synrecvsock() before the ehash insertion.

This allows the removal of one tcpsyncmss(), since tcpv4synrecvsock() will call it with the correct context.(CVE-2026-43198)

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

net: Drop the lock in skbmaytx_timestamp()

skbmaytxtimestamp() may acquire sock::skcallback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU.

Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed.

Drop the lock. Use READONCE() to obtain the individual pointer. Add a matching WRITEONCE() where the pointer are cleared.(CVE-2026-43216)

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

vhost: move vdpa group bound check to vhost_vdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)

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

mm/pagealloc: clear page->private in freepages_prepare()

Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values.

This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swapcountcontinued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash:

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__dosysswapoff+0x1151/0x1860

Fix this by clearing page->private in freepagesprepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)

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

scsi: hisisas: Fix NULL pointer exception during userscan()

userscan() invokes updated sasuserscan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->maxchannel) via scsiscanhostselected() in commit 37c4e72b0651 ("scsi: Fix sasuserscan() to handle wildcard and multi-channel scans"). However, hisisas supports only one channel, and the current value of maxchannel is 1. sasuser_scan() for channel 1 will trigger the following NULL pointer exception:

[ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0 [ 441.554699] Mem abort info: [ 441.554710] ESR = 0x0000000096000004 [ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits [ 441.554723] SET = 0, FnV = 0 [ 441.554726] EA = 0, S1PTW = 0 [ 441.554730] FSC = 0x04: level 0 translation fault [ 441.554735] Data abort info: [ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000 [ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000 [ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP [ 441.629589] Modules linked in: armspepmu armsmmuv3pmu tpmtisspi hisiuncoresllcpmu hisiuncorepapmu hisiuncorel3cpmu hisiuncorehhapmu hisiuncoreddrcpmu hisiuncorecpapmu hns3pmu hisiptt hisipciepmu tpmtiscore spidev spihisisfcv3xx hisiuncorepmu spidwmmio fuse hclge hclgecommon hisisec2 hisihpre hisizip hisiqm hns3 hisisasv3hw sm3ce sbsagwdt hnae3 hisisasmain uacce hisidma i2chisi dmmirror dmregionhash dmlog dmmod [ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT [ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 441.698277] pc : sasfinddevbyrphy+0x44/0x118 [ 441.702896] lr : sasfinddevbyrphy+0x3c/0x118 [ 441.707502] sp : ffff80009abbba40 [ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08 [ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00 [ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000 [ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020 [ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff [ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a [ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4 [ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030 [ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000 [ 441.782053] Call trace: [ 441.784488] sasfinddevbyrphy+0x44/0x118 (P) [ 441.789095] sastargetalloc+0x24/0xb0 [ 441.792920] scsialloctarget+0x290/0x330 [ 441.797010] __scsiscantarget+0x88/0x258 [ 441.801096] scsi_scanchannel+0x74/0xb8 [ 441.805008] scsiscanhostselected+0x170/0x188 [ 441.809615] sasuserscan+0xfc/0x148 [ 441.813267] storescan+0x10c/0x180 [ 441.816743] devattrstore+0x20/0x40 [ 441.820398] sysfskfwrite+0x84/0xa8 [ 441.824054] kernfsfopwriteiter+0x130/0x1c8 [ 441.828487] vfswrite+0x2c0/0x370 [ 441.831880] ksyswrite+0x74/0x118 [ 441.835271] _arm64syswrite+0x24/0x38 [ 441.839182] invokesyscall+0x50/0x120 [ 441.842919] el0svccommon.constprop.0+0xc8/0xf0 [ 441.847611] doel0svc+0x24/0x38 [ 441.850913] el0svc+0x38/0x158 [ 441.854043] el0t64synchandler+0xa0/0xe8 [ 441.858214] el0t64sync+0x1ac/0x1b0 [ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75) [ 441.867946] ---[ end trace 0000000000000000 ]---

Therefore ---truncated---(CVE-2026-43413)

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

ipvs: skip ipv6 extension headers for csum checks

Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.(CVE-2026-45850)

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

net: hns3: fix double free issue for tx spare buffer

In hns3setringparam(), a temporary copy (tmprings) of the ring structure is created for rollback. However, the txspare pointer in the original ring handle is incorrectly left pointing to the old backup memory.

Later, if memory allocation fails in hns3initallring() during the setup, the error path attempts to free all newly allocated rings. Since txspare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory.

The root cause is that the txspare field was not cleared after its value was saved in tmprings, leaving a dangling pointer.

Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new tx_spare fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the PASID entry.
2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dmawmb() in pasidset_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

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

quota: fix livelock between quotactl and freeze_super

When a filesystem is frozen, quotactlblock() enters a retry loop waiting for the filesystem to thaw. It acquires sumount, checks the freeze state, drops sumount and uses sbstartwrite() - sbend_write() pair to wait for the unfreeze.

However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.

The mechanism is as follows: 1. freezesuper() sets SBFREEZEWRITE and calls sbwaitwrite(). 2. sbwaitwrite() calls percpudownwrite(), which initiates synchronizercu(). 3. Simultaneously, quotactlblock() spins in its retry loop, immediately executing the sbstartwrite() - sbendwrite() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactlblock() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronizercu() in the freezer thread waits indefinitely for the quotactlblock() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync.

This results in a hang of the freezer process and 100% CPU usage by the quota process.

While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:

# mkfs.ext4 -O quota /dev/sda 2g && mkdir amount # mount /dev/sda -o quota,usrquota,grpquota amount # taskset -c 3 bash -c "while true; do xfsfreeze -f amount; \ xfsfreeze -u amount; done" & # taskset -c 3 bash -c "while true; do quotaon amount; \ quotaoff amount; done" &

Adding condresched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronizercu() in percpudownwrite() to complete.(CVE-2026-45895)

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

fat: avoid parent link count underflow in rmdir

Corrupted FAT images can leave a directory inode with an incorrect inlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls dropnlink(dir) and can drive inlink to 0, triggering the WARNON in drop_nlink().

Add a sanity check in vfatrmdir() and msdosrmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

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

sched/rt: Skip currently executing CPU in rtonextcpu()

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVERTPUSHIPI enabled, they send IPIs to CPU0 to drive the execution of rtopushirqworkfunc. During pushrttask on CPU0, if nexttask->prio < rq->donor->prio, reschedcurr() sets NEEDRESCHED and after the push operation completes, CPU0 calls rtonextcpu(). Since only CPU0 is overloaded in this scenario, rtonextcpu() should ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tellcputopush() during LB increments rd->rtoloopnext. Even when rd->rtocpu is set to -1, the mismatch between rd->rtoloop and rd->rtoloopnext forces rtonextcpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rtnrmigratory && rtnrtotal > 1), it gets reselected, causing CPU0 to queue irqwork to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pullrttasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.

The trigging scenario is as follows:

     cpu0                      cpu1                    cpu2
                            pull_rt_task
                          tell_cpu_to_push
             <------------irq_work_queue_on

rtopushirqworkfunc pushrttask reschedcurr(rq) pullrttask rtonextcpu tellcputopush <-------------------------- atomicinc(rtoloopnext) rd->rtoloop != next rtonextcpu irqworkqueueon rtopushirqwork_func

Fix redundant self-IPI by filtering the initiating CPU in rtonextcpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)

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

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4putsuper() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4putsuper+0x48c/0x590 [ext4]

Tracing the failure shows that the warning fires due to an sdirtyclusterscounter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4mbmarkdiskspaceused() and the caller ext4mbnew_blocks().

First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4handledirtymetadata() call(s) made from ext4mbmarkcontext(). The changed value is non-zero at this point, so ext4mbmarkdiskspaceused() does not exit after the error bubbles up from ext4mbmarkcontext(). Instead, the former decrements both cluster counters and returns the error up to ext4mbnewblocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.

To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4mbnewblocks() is responsible for acquiring cluster reservation (via ext4claimfreeclusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)

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

ext4: fix e4b bitmap inconsistency reports

A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:

ext4mbcomplexscangroup:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks

Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice:

foliolock ext4mbloadbuddy __migratefolio check ref count foliomc_copy __filemapgetfolio folio_tryget(folio) ...... mbmarkused ext4mbunloadbuddy _foliomigratemapping folioreffreeze foliounlock

The root cause of this issue is that the fast path of loadbuddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in loadbuddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window.

Additionally, this change addresses the following issues:

When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered:

corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc

Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:

ext4mbloadbuddy ext4mbloadbuddy __filemapgetfolio(create|lock) foliolock ext4mbinitcache foliomarkuptodate _filemapgetfolio(no lock) ...... mbmarkused mbmarkuseddouble mbcmpbitmaps mbsetbits(e4b->bdbitmap) foliounlock

The original logic assumed that since mbcmpbitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.(CVE-2026-45942)

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

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
4. Fully zero out the entry only after the invalidation is complete.

Also, add a dmawmb() to contextset_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

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

ext4: fix memory leak in ext4extshift_extents()

In ext4extshiftextents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4find_extent(), leading to a memory leak.

Fix this by jumping to the out label to ensure the path is properly released.(CVE-2026-45948)

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

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash.

[ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidleenterstate+0x2c4/0x668

Fix this by adding a bail-out in cpuidleselect() that returns state 0 directly when statecount <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

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

ext4: don't set EXT4GETBLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with dioreadnolock enabled, EXT4GETBLOCKSPREIO was set to split an existing large unwritten extent. However, EXT4GETBLOCKSCONVERT was set when calling ext4splitconvert_extents(), which may potentially result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, ext4iomapalloc() call ext4mapblocks() with EXT4GETBLOCKSPREIO, EXT4GETBLOCKSUNWRITEXT and EXT4GETBLOCKSCREATE flags set. ext4mapblocks() find this extent and call ext4splitconvertextents() with EXT4GETBLOCKS_CONVERT and the above flags set.

Then, ext4splitconvertextents() calls ext4splitextent() with EXT4EXTMAYZEROOUT, EXT4EXTMARKUNWRIT2 and EXT4EXTDATAVALID2 flags set, and it calls ext4splitextentat() to split the second half with EXT4EXTDATAVALID2, EXT4EXTMARKUNWRIT1, EXT4EXTMAYZEROOUT and EXT4EXTMARKUNWRIT2 flags set. However, ext4splitextentat() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4EXTDATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.

[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4GETBLOCKSCONVERT when splitting an unwritten extent before submitting I/O, and make ext4splitconvertextents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.(CVE-2026-45985)

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

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

If loading L1's CR3 fails on a nested #VMEXIT, nestedsvmvmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nestedsvmvmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nestedsvmvmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fbdeferrediostate. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fbinfo and the contained deferred I/O meanwhile goes away, clear struct fbdeferredio_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)

In the Linux kernel, the vlandevsetegresspriority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)

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

eventpoll: fix ep_remove struct eventpoll / struct file UAF

epremove() (via epremovefile()) cleared file->fep under file->flock but then kept using @file inside the critical section (isfileepoll(), hlistdelrcu() through the head, spinunlock). A concurrent _fput() taking the eventpollrelease() fastpath in that window observed the transient NULL, skipped eventpollreleasefile() and ran to fop->release / filefree().

For the epoll-watches-epoll case, fop->release is epeventpollrelease() -> epclearandput() -> epfree(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlisthead is exactly where epi->fllink.pprev points, so the subsequent hlistdelrcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLABTYPESAFEBYRCU, so the slot backing @file could be recycled by allocemptyfile() -- reinitializing flock and fep -- while epremove() is still nominally inside that lock. The upshot is an attacker-controllable kmemcachefree() against the wrong slab cache.

Pin @file via epifget() at the top of epremove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds _fput() off and transitively keeps the watched struct eventpoll alive across the hlistdelrcu() and the flock use, closing both UAFs.

If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing fep, that path takes the eventpollrelease() slow path into eventpollreleasefile() and blocks on ep->mtx until the waiter side's epclearandput() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing eprefcountdecandtest() in epclearandput() cannot free the eventpoll out from under eventpollreleasefile(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpollreleasefile() on this epi, so drop the now-redundant re-check of epi->dying under flock. The cheap lockless READONCE(epi->dying) fast-path bailout stays.(CVE-2026-46242)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dclink NULL handling in HPD init amdgpudmhpdinit() may see connectors without a valid dclink. The code already checks dclink for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dclink early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c:940 amdgpudmhpdinit() error: we previously assumed 'dclink' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 */ 927 usepolling |= 928 amdgpudmconnector->dclink && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dcconnectorsupportsanalog(amdgpudmconnector->dclink->linkid.id); 930 931 dclink = amdgpudmconnector->dclink; dclink assigned here. 932 933 /* 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpdrx types aren't. IOW, amdgpuirqget/put on 937 * hpdrx isn't available. DM currently controls hpdrx 938 * explicitly with dcinterruptset() 939 */ --> 940 if (dclink->irqsourcehpd != DCIRQSOURCEINVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irqtype = dclink->irqsourcehpd - DCIRQSOURCEHPD1; 942 /* 943 * TODO: There's a mismatch between modeinfo.num_hpd 944 * and what bios reports as the # of connectors with hpd The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)

In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading realparent in dotaskstat() When reading /proc/[pid]/stat, dotaskstat() accesses task->realparent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- dotaskstat var = task->realparent releasetask callrcu(delayedputtaskstruct) tasktgidnrns(var) rcureadlock <--- Too late to protect task->realparent! taskpidptr <--- UAF! rcureadunlock This patch uses taskppidnrns() instead of tasktgidnrns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)