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

wifi: iwlwifi: mvm: ensure offloading TID queue exists

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050115-CVE-2024-27056-98c0@gregkh/T

Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereportedev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.

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

drm/vmwgfx: Fix the lifetime of the bo cursor memory

The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmwplanestate instead of using the builtin mapandcache were trying to handle the lifetime of the mapped memory themselves, leading to crashes.

Use the mapandcache instead of trying to manage the lifetime of the buffer objects held by the vmwplanestate.

Fixes kernel oops'es in IGT's kmscursorlegacy forked-bo.

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

net/mlx5e: fix a double-free in arfscreategroups

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051730-CVE-2024-35835-d75f@gregkh/T

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

mlxsw: spectrumacltcam: Fix stack corruption

When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.

One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.

In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.

Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.

Add a test case to make sure the machine does not crash when this condition is hit.

[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxswspacltcamgroupupdate+0x116/0x120 [...] dumpstacklvl+0x36/0x50 panic+0x305/0x330 stackchkfail+0x15/0x20 mlxswspacltcamgroupupdate+0x116/0x120 mlxswspacltcamgroupregionattach+0x69/0x110 mlxswspacltcamvchunkget+0x492/0xa20 mlxswspacltcamventryadd+0x25/0xe0 mlxswspaclruleadd+0x47/0x240 mlxswspflowerreplace+0x1a9/0x1d0 tcsetupcbadd+0xdc/0x1c0 flhwreplacefilter+0x146/0x1f0 flchange+0xc17/0x1360 tcnewtfilter+0x472/0xb90 rtnetlinkrcvmsg+0x313/0x3b0 netlinkrcvskb+0x58/0x100 netlinkunicast+0x244/0x390 netlinksendmsg+0x1e4/0x440 syssendmsg+0x164/0x260 syssendmsg+0x9a/0xe0 syssendmsg+0x7a/0xc0 dosyscall64+0x40/0xe0 entrySYSCALL64afterhwframe+0x63/0x6b

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

cppccpufreq: Fix possible null pointer dereference

cppccpufreqgetrate() and hisicppccpufreqgetrate() can be called from different places with various parameters. So cpufreqcpuget() can return null as 'policy' in some circumstances. Fix this bug by adding null return check.

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

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

irqchip/gic-v3-its: Prevent double free on error

The error handling path in itsvpeirqdomainalloc() causes a double free when itsvpeinit() fails after successfully allocating at least one interrupt. This happens because itsvpeirqdomainfree() frees the interrupts along with the area bitmap and the vproppage and itsvpeirqdomainalloc() subsequently frees the area bitmap and the vproppage again.

Fix this by unconditionally invoking itsvpeirqdomainfree() which handles all cases correctly and by removing the bitmap/vproppage freeing from itsvpeirqdomainalloc().

[ tglx: Massaged change log ]

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

mlxsw: spectrumacltcam: Fix possible use-after-free during rehash

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T

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

mlxsw: spectrumacltcam: Fix possible use-after-free during activity update

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051741-CVE-2024-35855-c1fb@gregkh/T

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

netfilter: nftables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.

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

crypto: qat - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the resetdata structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the resetdata structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.

This results in a KFENCE bug notice.

BUG: KFENCE: use-after-free read in adfdeviceresetworker+0x38/0xa0 [intelqat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adfdeviceresetworker+0x38/0xa0 [intelqat] processonework+0x173/0x340

To resolve this race condition, the memory associated to the container of the workstruct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completiondone() function.

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

netfilter: nftables: Fix potential data-race in nftobjtypeget()

nftunregisterobj() can concurrent with nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in nftobjtypeget(), and use rcureadlock() in the caller nftobjtypeget() to protect the entire type query process.

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

USB: core: Fix deadlock in port "disable" sysfs attribute

The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:

Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and devicedel() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then.

But the disableshow() or disablestore() routine can't return until after it has acquired the lock.

The resulting deadlock can be avoided by calling sysfsbreakactiveprotection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hubget().

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

USB: core: Fix deadlock in usbdeauthorizeinterface()

Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interfaceauthorizedstore() function is the only one which acquires a device lock on an ancestor device: It calls usbdeauthorizeinterface(), which locks the interface's parent USB device.

The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, devicedel() waits for all ongoing sysfs attribute callbacks to complete. But usbdeauthorizeinterface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfsbreakactiveprotection() function, which tells sysfs not to wait for the attribute callback.

Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>

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

netfilter: nftables: Fix potential data-race in nftexprtypeget()

nftunregisterexpr() can concurrent with nftexprtypeget(), and there is not any protection when iterate over nftablesexpressions list in nftexprtypeget(). Therefore, there is potential data-race of nftablesexpressions list entry.

Use listforeachentryrcu() to iterate over nftablesexpressions list in nftexprtypeget(), and use rcureadlock() in the caller nftexprtypeget() to protect the entire type query process.

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

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcountwarnsaturate+0x9c/0xe0 Workqueue: nfsiod nfsdirectwriteschedulework [nfs] RIP: 0010:refcountwarnsaturate+0x9c/0xe0 PKRU: 55555554 Call Trace: ? warn+0x9f/0x130 ? refcountwarnsaturate+0x9c/0xe0 ? reportbug+0xcc/0x150 ? handlebug+0x3d/0x70 ? excinvalidop+0x16/0x40 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0x9c/0xe0 nfsdirectwriteschedulework+0x237/0x250 [nfs] processonework+0x12f/0x4a0 workerthread+0x14e/0x3b0 ? ZSTDgetCParamsinternal+0x220/0x220 kthread+0xdc/0x120 ? btfnamevalid+0xa0/0xa0 retfromfork+0x1f/0x30

This is because we're completing the nfsdirectrequest twice in a row.

The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have

if (nfscommitend(cinfo.mds)) nfsdirectwritecomplete(dreq);

However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfsdirectrequest twice.

The only other place we use nfsgenericcommitlist() is in nfscommitinode, which wraps this call in a

nfscommitbegin(); nfscommitend();

Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with getdreq()/putdreq() calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.

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

net: iptunnel: prevent perpetual headroom growth

syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasanreport+0xda/0x110 mm/kasan/report.c:588 skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 skbflowdissectflowkeys include/linux/skbuff.h:1514 [inline] skbgethash net/core/flowdissector.c:1791 [inline] skbgethash+0xc7/0x540 net/core/flowdissector.c:1856 skbgethash include/linux/skbuff.h:1556 [inline] iptunnelxmit+0x1855/0x33c0 net/ipv4/iptunnel.c:748 ipiptunnelxmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x42c/0x5d0 net/core/neighbour.c:1592 ... ipfinishoutput2+0x833/0x2550 net/ipv4/ipoutput.c:235 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 .. iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1dbc/0x33c0 net/ipv4/iptunnel.c:831 ipgrexmit+0x4a1/0x980 net/ipv4/ipgre.c:665 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 ...

The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: skbpull(skb, skbnetworkoffset(skb));

... but skbnetworkoffset() returns a negative offset and skbpull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.

The negative value is returned because skb->head and skb->data distance is more than 64k and skb->networkheader (u16) has wrapped around.

The bug is in the iptunnel infrastructure, which can cause dev->neededheadroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0.

2). iptunnelxmit for gre0 bumps gre0->neededheadroom based on the future output device, rt.dev->neededheadroom (ipip0).

3). ip output / startxmit moves skb on to ipip0. which runs the same code path again (xmit recursion).

4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet.

tunl0->neededheadroom is then incremented based on the (already bumped) gre0 device headroom.

This repeats for every future packet:

gre0->neededheadroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 neededheadroom was increased.

For each subsequent packet, gre/ipip0->neededheadroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k.

Once that happens, skb->networkheader (u16) wraps around when pskbexpandhead tries to make sure that skbnetworkoffset() is unchanged after the headroom expansion/reallocation.

After this skbnetworkoffset(skb) returns a different (and negative) result post headroom expansion.

The next trip to neigh layer (or anything else that would skbpull the network header) makes skb->data point to a memory location outside skb->head area.

v2: Cap the neededheadroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.

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

Bluetooth: Avoid potential use-after-free in hcierrorreset

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040403-CVE-2024-26801-da9f@gregkh/T

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

mtd: require write permissions for locking and badblock ioctls

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.

MEMSETBADBLOCK modifies the bad block table.

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

Squashfs: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fillmetaindex().

That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following sequence of events:

1. Fillmetaindex() is called to allocate (via emptymetaindex()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).

2. When fillmetaindex() is subsequently called again on another read operation, locatemetaindex() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix]

drm/amdgpu: fix use-after-free bug

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

wifi: mt76: replace skbput with skbputzero

Avoid potentially reusing uninitialized data

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmetsqdestroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmetsqdestroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before killandconfirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmetsqdestroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41091 has been assigned to the TUN side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens, since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41090 has been assigned to the TAP side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

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

drm/radeon: check bova->bo is non-NULL before using it

The call to radeonvmclearfreed might clear bova->bo, so we have to check it before dereferencing it.

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

firmware: csdsp: Use strnlen() on name fields in V1 wmfw files

Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.

In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. csdsp should protect against overrunning the array if the NUL terminator is missing.

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

udp: Set SOCKRCUFREE earlier in udplibgetport().

syzkaller triggered the warning [0] in udpv4earlydemux().

In udpv[46]earlydemux() and sklookup(), we do not touch the refcount of the looked-up sk and use sockpfree() as skb->destructor, so we check SOCKRCUFREE to ensure that the sk is safe to access during the RCU grace period.

Currently, SOCKRCUFREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCKRCUFREE check is done too early in udpv[46]earlydemux() and sklookup(), so there could be a small race window:

CPU1 CPU2 ---- ---- udpv4earlydemux() udplibgetport() | |- hlistaddheadrcu() |- sk = udp4libdemuxlookup() | |- DEBUGNETWARNONONCE(skisrefcounted(sk)); - socksetflag(sk, SOCKRCUFREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCKRCUFREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

[0]: WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> iprcvfinishcore.constprop.0+0xbdd/0xd20 net/ipv4/ipinput.c:349 iprcvfinish+0xda/0x150 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] iprcv+0x16c/0x180 net/ipv4/ipinput.c:569 netifreceiveskbonecore+0xb3/0xe0 net/core/dev.c:5624 netifreceiveskb+0x21/0xd0 net/core/dev.c:5738 netifreceiveskbinternal net/core/dev.c:5824 [inline] netifreceiveskb+0x271/0x300 net/core/dev.c:5884 tunrxbatched drivers/net/tun.c:1549 [inline] tungetuser+0x24db/0x2c50 drivers/net/tun.c:2002 tunchrwriteiter+0x107/0x1a0 drivers/net/tun.c:2048 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x76f/0x8d0 fs/readwrite.c:590 ksyswrite+0xbf/0x190 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x41/0x50 fs/readwrite.c:652 x64syscall+0xe66/0x1990 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4b/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---

firmware: csdsp: Prevent buffer overrun when processing V2 alg headers