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

accel/amdxdna: Fix runtime suspend deadlock when there is pending job

The runtime suspend callback drains the running job workqueue before suspending the device. If a job is still executing and calls pmruntimeresumeandget(), it can deadlock with the runtime suspend path.

Fix this by moving pmruntimeresumeandget() from the job execution routine to the job submission routine, ensuring the device is resumed before the job is queued and avoiding the deadlock during runtime suspend.

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

ASoC: amd: acp-mach-common: Add missing error check for clock acquisition

The acpcardrt5682init() and acpcardrt5682sinit() functions did not check the return values of clkget(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions.

Fix this by: 1. Changing clkget() to the device-managed devmclkget(). 2. Adding ISERR() checks immediately after each clock acquisition.

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

srcu: Use irqwork to start GP in tiny SRCU

Tiny SRCU's srcugpstartifneeded() directly calls schedulework(), which acquires the workqueue pool->lock.

This causes a lockdep splat when callsrcu() is called with a scheduler lock held, due to:

callsrcu() [holding pilock] srcugpstartifneeded() schedulework() -> pool->lock

workqueueinit() / createworker() [holding pool->lock] wakeupprocess() -> trytowakeup() -> pilock

Also add irqworksync() to cleanupsrcustruct() to prevent a use-after-free if a queued irqwork fires after cleanup begins.

Tested with rcutorture SRCU-T and no lockdep warnings.

[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irqwork to start processsrcu()" ]

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

mshv: Fix error handling in mshvregionpin

The current error handling has two issues:

First, pinuserpagesfast() can return a short pin count (less than requested but greater than zero) when it cannot pin all requested pages. This is treated as success, leading to partially pinned regions being used, which causes memory corruption.

Second, when an error occurs mid-loop, already pinned pages from the current batch are not properly accounted for before calling mshvregioninvalidatepages(), causing a page reference leak.

Treat short pins as errors and fix partial batch accounting before cleanup.

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

Bluetooth: hcisync: hcicmdsyncqueueonce() return -EEXIST if exists

hcicmdsyncqueueonce() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.

Change the function to return -EEXIST if queue item already exists.

Modify all callsites to handle that.

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

ALSA: ctxfi: Check the error for index mapping

The ctxfi driver blindly assumed a proper value returned from daiodeviceindex(), but it's not always true. Add a proper error check to deal with the error from the function.

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

ALSA: ctxfi: Don't enumerate SPDIF1 at DAIO initialization

The recent refactoring of xfi driver changed the assignment of atc->daios[] at atcgetresources(); now it loops over all enum DAIOTYP entries while it looped formerly only a part of them. The problem is that the last entry, SPDIF1, is a special type that is used only for hw20k1 CTSB073X model (as a replacement of SPDIFIO), and there is no corresponding definition for hw20k2. Due to the lack of the info, it caused a kernel crash on hw20k2, which was already worked around by the commit b045ab3dff97 ("ALSA: ctxfi: Fix missing SPDIFI1 index handling").

This patch addresses the root cause of the regression above properly, simply by skipping the incorrect SPDIF1 type in the parser loop.

For making the change clearer, the code is slightly arranged, too.

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

blktrace: fix thiscpuread/write in preemptible context

tracingrecordcmdline() internally uses thiscpuread() and thiscpuwrite() on the per-CPU variable tracecmdlinesave, and tracesavecmdline() explicitly asserts preemption is disabled via lockdepassertpreemptiondisabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probewakeupschedswitch() / probewakeup()).

blkaddtrace() was calling tracingrecordcmdline(current) early in the blktracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:

blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)

[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 [ 81.362895] checkpreemptiondisabled+0xce/0xe0 [ 81.362902] tracingrecordcmdline+0x10/0x40 [ 81.362923] blkaddtrace+0x307/0x5d0 [ 81.362934] ? lockacquire+0xe0/0x300 [ 81.362940] ? ioviterextractpages+0x101/0xa30 [ 81.362959] blkaddtracebio+0x106/0x1e0 [ 81.362968] submitbionoacctnocheck+0x24b/0x3a0 [ 81.362979] ? lockdepinitmaptype+0x58/0x260 [ 81.362988] submitbiowait+0x56/0x90 [ 81.363009] blkdevdirectIOsimple+0x16c/0x250 [ 81.363026] ? pfxsubmitbiowaitendio+0x10/0x10 [ 81.363038] ? rcureadlockanyheld+0x73/0xa0 [ 81.363051] blkdevreaditer+0xc1/0x140 [ 81.363059] vfsread+0x20b/0x330 [ 81.363083] ksysread+0x67/0xe0 [ 81.363090] dosyscall64+0xbf/0xf00 [ 81.363102] entrySYSCALL64afterhwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] </TASK>

The same BUG fires from blkaddtraceplug(), blkaddtraceunplug(), and blkaddtracerq() paths as well.

The purpose of tracin ---truncated---

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

accel/amdxdna: Fix NULL pointer dereference of mgmtchann

mgmtchann may be set to NULL if the firmware returns an unexpected error in aie2sendmgmtmsgwait(). This can later lead to a NULL pointer dereference in aie2hwstop().

Fix this by introducing a dedicated helper to destroy mgmtchann and by adding proper NULL checks before accessing it.

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

accel/amdxdna: Fix dead lock for suspend and resume

When an application issues a query IOCTL while auto suspend is running, a deadlock can occur. The query path holds devlock and then calls pmruntimeresumeandget(), which waits for the ongoing suspend to complete. Meanwhile, the suspend callback attempts to acquire devlock and blocks, resulting in a deadlock.

Fix this by releasing devlock before calling pmruntimeresumeandget() and reacquiring it after the call completes. Also acquire devlock in the resume callback to keep the locking consistent.

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

usb: gadget: fncm: Fix netdevice lifecycle with devicemove

The network device outlived its parent gadget device during disconnection, resulting in dangling sysfs links and null pointer dereference problems.

A prior attempt to solve this by removing SETNETDEVDEV entirely [1] was reverted due to power management ordering concerns and a NO-CARRIER regression.

A subsequent attempt to defer netdevice allocation to bind [2] broke 1:1 mapping between function instance and network device, making it impossible for configfs to report the resolved interface name. This results in a regression where the DHCP server fails on pmOS.

Use devicemove to reparent the netdevice between the gadget device and /sys/devices/virtual/ across bind/unbind cycles. This preserves the network interface across USB reconnection, allowing the DHCP server to retain their binding.

Introduce getherattachgadget()/getherdetachgadget() helpers and use free(detachgadget) macro to undo attachment on bind failure. The bindcount ensures devicemove executes only on the first bind.

[1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/ [2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/

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

net: Drop the lock in skbmaytxtimestamp()

skbmaytxtimestamp() may acquire sock::skcallbacklock. 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 ->sksocket 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.

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

ixgbevf: add missing negotiatefeatures op to Hyper-V ops table

Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") added the .negotiatefeatures callback to ixgbemacoperations and populated it in ixgbevfmacops, but forgot to add it to ixgbevfhvmacops. This leaves the function pointer NULL on Hyper-V VMs.

During probe, ixgbevfnegotiateapi() calls ixgbevfsetfeatures(), which unconditionally dereferences hw->mac.ops.negotiatefeatures(). On Hyper-V this results in a NULL pointer dereference:

BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events workforcpufn RIP: 0010:0x0 [...] Call Trace: ixgbevfnegotiateapi+0x66/0x160 [ixgbevf] ixgbevfswinit+0xe4/0x1f0 [ixgbevf] ixgbevfprobe+0x20f/0x4a0 [ixgbevf] localpciprobe+0x50/0xa0 workforcpufn+0x1a/0x30 [...]

Add ixgbevfhvnegotiatefeaturesvf() that returns -EOPNOTSUPP and wire it into ixgbevfhvmacops. The caller already handles -EOPNOTSUPP gracefully.

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.

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

netfilter: nfnetlinklog: initialize nfgenmsg in NLMSGDONE terminator

When batching multiple NFLOG messages (inst->qlen > 1), nfulnlsend() appends an NLMSGDONE terminator with sizeof(struct nfgenmsg) payload via nlmsgput(), but never initializes the nfgenmsg bytes. The nlmsgput() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSGDONE message body.

Use nfnlmsgput() to build the NLMSGDONE terminator, which initializes the nfgenmsg payload via nfnlfillhdr(), consistent with how buildpacketmessage() already constructs NFULNLMSGPACKET headers.

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

l2tp: Drop large packets with UDP encap

syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code.

syzbot's repro:

r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)

It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tpxmitcore doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites.

Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire.

syzbot's stack trace (with my patch applied):

len >= 65536u WARNING: ./include/linux/udp.h:38 at udpsetlenshort include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tpxmitcore net/l2tp/l2tpcore.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tpxmitskb+0x1204/0x18d0 net/l2tp/l2tpcore.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udpsetlenshort include/linux/udp.h:38 [inline] RIP: 0010:l2tpxmitcore net/l2tp/l2tpcore.c:1293 [inline] RIP: 0010:l2tpxmitskb+0x1204/0x18d0 net/l2tp/l2tpcore.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: <TASK> pppol2tpsendmsg+0x40a/0x5f0 net/l2tp/l2tpppp.c:302 socksendmsgnosec net/socket.c:727 [inline] socksendmsg net/socket.c:742 [inline] sockwriteiter+0x503/0x550 net/socket.c:1195 doiterreadvwritev+0x619/0x8c0 fs/readwrite.c:-1 vfswritev+0x33c/0x990 fs/readwrite.c:1059 dowritev+0x154/0x2e0 fs/readwrite.c:1105 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x14d/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIGRAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 </TASK>

[1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

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

net: sched: clsapi: fix tcchainfillnode to initialize tcminfo to zero to prevent an info-leak

When building netlink messages, tcchainfillnode() never initializes the tcminfo field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field.

The fix simply zeroes tcminfo alongside the other fields that are already initialized.

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

netfilter: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpectinit(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNFNAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.

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 NFQUEUE immediate verdicts to address this issue.

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

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

net: ftgmac100: fix ring allocation unwind on open failure

ftgmac100allocrings() allocates rxskbs, txskbs, rxdes, txdes, and rxscratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function.

Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.

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

netfilter: xtmultiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

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

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

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

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

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

xfrm: clear trailing padding in buildpolexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuserpolexpire.

The padding bytes after the u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().

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

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

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

rxrpc: Fix call removal to use RCU safe deletion

Fix rxrpc call removal from the rxnet->calls list to use listdelrcu() rather than listdelinit() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop.

This, however, means that listempty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by:

Firstly, make rxrpcdestroyallcalls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call condresched() or to remove calls from the list here, thereby eliminating the need for rxrpcputcall() to check for that.

rxrpcputcall() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.

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

rxrpc: fix reference count leak in rxrpcserverkeyring()

This patch fixes a reference count leak in rxrpcserverkeyring() by checking if rx->securities is already set.

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

RDMA/irdma: Fix deadlock during netdev reset with active connections

Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering devicedelete and subsequent client removal. During client removal, uverbsclient waits for QP reference count to reach zero while cmaclient holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.

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

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bondalb.c already handle this NULL-slave state safely:

- rlbupdateclient returns early on !clientinfo->slave - rlbrequpdateslaveclients, rlbclearslave, and rlbrebalance compare slave values before visiting - lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.