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

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>

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

netfilter: nftables: don't skip expired elements during walk

There is an asymmetry between commit/abort and preparation phase if the following conditions are met:

1. set is a verdict map ("1.2.3.4 : jump foo") 2. timeouts are enabled

In this case, following sequence is problematic:

1. element E in set S refers to chain C 2. userspace requests removal of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)

If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed.

Then, when set is culled, ->destroy callback will zap the element via nftablessetelemdestroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nftchain structure.

Update pipapoget() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.

HID: core: zero-initialize the report buffer

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

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.

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

ext4: fix corruption during on-line resize

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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

Input: aiptek - properly check endpoint type

Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

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

Bluetooth: btintel: Fix null ptr deref in btintelreadversion

If hcicmdsynccomplete() is triggered and skb is NULL, then hdev->reqskb is NULL, which will cause this issue.

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

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

calipso: fix memory leak in netlblcalipsoaddpass()

If IPv6 support is disabled at boot (ipv6.disable=1), the calipsoinit() -> netlblcalipsoopsregister() function isn't called, and the netlblcalipsoopsget() function always returns NULL. In this case, the netlblcalipsoaddpass() function allocates memory for the doidef variable but doesn't free it with the calipsodoifree().

BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlblcalipsoaddpass net/netlabel/netlabelcalipso.c:76 [inline] [<...>] netlblcalipsoadd+0x22e/0x4f0 net/netlabel/netlabelcalipso.c:111 [<...>] genlfamilyrcvmsgdoit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] [<...>] genlrcvmsg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlinkrcvskb+0x14d/0x440 net/netlink/afnetlink.c:2515 [<...>] genlrcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] [<...>] netlinkunicast+0x54b/0x800 net/netlink/afnetlink.c:1339 [<...>] netlinksendmsg+0x90a/0xdf0 net/netlink/afnetlink.c:1934 [<...>] socksendmsgnosec net/socket.c:651 [inline] [<...>] socksendmsg+0x157/0x190 net/socket.c:671 [<...>] syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] syssendmsg+0xf8/0x170 net/socket.c:2396 [<...>] syssendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entrySYSCALL64afterhwframe+0x61/0xc6

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller

[PM: merged via the LSM tree at Jakub Kicinski request]

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

The Linux kernel CVE team has assigned CVE-2024-27399 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T

gfs2: Fix kernel NULL pointer dereference in gfs2rgrpdump

Syzkaller has reported a NULL pointer dereference when accessing rgd->rdrgl in gfs2rgrpdump(). This can happen when creatingrgd->rdgl fails in readrindexentry(). Add a NULL pointer check in gfs2rgrpdump() to prevent that.

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

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.

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

drm/amd/display: Fix potential null-deref in dmresume

[Why] Fixing smatch error: dmresume() error: we previously assumed 'aconnector->dclink' could be null

[How] Check if dclink null at the beginning of the loop, so further checks can be dropped.

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

arm64: fix oops in concurrently setting insnemulation sysctls

emulationprochandler() changes table->data for procdointvecminmax and can generate the following Oops if called concurrently with itself:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | updateinsnemulationmode+0xc0/0x148 | emulationprochandler+0x64/0xb8 | procsyscallhandler+0x9c/0xf8 | procsyswrite+0x18/0x20 | vfswrite+0x20/0x48 | vfswrite+0xe4/0x1d0 | ksyswrite+0x70/0xf8 | arm64syswrite+0x20/0x28 | el0svccommon.constprop.0+0x7c/0x1c0 | el0svchandler+0x2c/0xa0 | el0svc+0x8/0x200

To fix this issue, keep the table->data as &insn->currentmode and use containerof() to retrieve the insn pointer. Another mutex is used to protect against the currentmode update but not for retrieving insnemulation as table->data is no longer changing.

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

f2fs: fix to avoid use f2fsbugon() in f2fsnewnodepage()

As Dipanjan Das <mail.dipanjan.das@gmail.com> reported, syzkaller found a f2fs bug as below:

RIP: 0010:f2fsnewnodepage+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Call Trace: writeallxattrs fs/f2fs/xattr.c:487 [inline] f2fssetxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fssetxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fsxattrgenericset+0x133/0x170 fs/f2fs/xattr.c:86 vfssetxattr+0x115/0x180 fs/xattr.c:182 vfssetxattrnoperm+0x125/0x5f0 fs/xattr.c:216 vfssetxattrlocked+0x1cf/0x260 fs/xattr.c:277 vfssetxattr+0x13f/0x330 fs/xattr.c:303 setxattr+0x146/0x160 fs/xattr.c:611 pathsetxattr+0x1a7/0x1d0 fs/xattr.c:630 dosyslsetxattr fs/xattr.c:653 [inline] sesyslsetxattr fs/xattr.c:649 [inline] x64syslsetxattr+0xbd/0x150 fs/xattr.c:649 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x46/0xb0

NAT entry and nat bitmap can be inconsistent, e.g. one nid is free in nat bitmap, and blkaddr in its NAT entry is not NULLADDR, it may trigger BUGON() in f2fsnewnodepage(), fix it.

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

udmabuf: Set the DMA mask for the udmabuf device (v2)

If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here:

WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 dmamapsgattrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dmamapsgattrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dmamapsgtable+0x70/0xf0 kernel/dma/mapping.c:264 getsgtable.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begincpuudmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dmabufbegincpuaccess+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dmabufioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:874 [inline] sesysioctl fs/ioctl.c:860 [inline] x64sysioctl+0x193/0x200 fs/ioctl.c:860 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

v2: Dont't forget to deregister if DMA mask setup fails.

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

media: venus: hfi: avoid null dereference in deinit

If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the coredeinit function anymore.

Avoid this null pointer derefence by skipping the call when necessary.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac

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

net: systemport: fix potential memory leak in bcmsysportxmit()

The bcmsysportxmit() returns NETDEVTXOK without freeing skb in case of dmamapsingle() fails, add devkfreeskb() to fix it.

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

nilfs2: fix potential deadlock with newly created symlinks

Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock.

This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem().

This is not a problem for symlinks read from the backing device, because the GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held:

Fix this issue by dropping the GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.

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

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove():

[ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] vfsremovexattr+0x92/0xc0 [ 57.339182] vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...]

Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: 1st: in ocfs2xacleanupvaluetruncate(); 2nd: returning back to ocfs2xaremove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.

ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize()

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

media: v4l2-tpg: prevent the risk of a division by zero

As reported by Coverity, the logic at tpgprecalculateline() blindly rescales the buffer even when scaledwitdh is equal to zero. If this ever happens, this will cause a division by zero.

Instead, add a WARNONONCE() to trigger such cases and return without doing any precalculation.

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

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AFINET

Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen{s,d}, since that's how prefixlen is going to be used later on.

be2net: fix potential memory leak in bexmit()

arm64: probes: Fix uprobes for big-endian kernels

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

s390/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.

Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

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

net/sun382586: fix potential memory leak in sun382586sendpacket()

The sun382586sendpacket() returns NETDEVTXOK without freeing skb in case of skb->len being too long, add devkfreeskb() to fix it.