fbdev: smscufx: properly copy ioctl memory to kernelspace

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

netfilter: nftables: fix use-after-free in nftablesaddchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschaindestroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcureadlock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchaindel() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

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

btrfs: fix use-after-free warning in btrfsgetorcreatedelayednode()

Previously, btrfsgetorcreatedelayednode() set the delayednode's refcount before acquiring the root->delayednodes lock. Commit e8513c012de7 ("btrfs: implement reftracker for delayednodes") moved refcountset inside the critical section, which means there is no longer a memory barrier between setting the refcount and setting btrfsinode->delayednode.

Without that barrier, the stores to node->refs and btrfsinode->delayednode may become visible out of order. Another thread can then read btrfsinode->delayednode and attempt to increment a refcount that hasn't been set yet, leading to a refcounting bug and a use-after-free warning.

The fix is to move refcountset back to where it was to take advantage of the implicit memory barrier provided by lock acquisition.

Because the allocations now happen outside of the lock's critical section, they can use GFPNOFS instead of GFPATOMIC.

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

erspan: Initialize optionslen before referencing options.

The struct iptunnelinfo has a flexible array member named options that is protected by a countedby(optionslen) attribute.

The compiler will use this information to enforce runtime bounds checking deployed by FORTIFYSOURCE string helpers.

As laid out in the GCC documentation, the counter must be initialized before the first reference to the flexible array member.

After scanning through the files that use struct iptunnelinfo and also refer to options or optionslen, it appears the normal case is to use the iptunnelinfooptsset() helper.

Said helper would initialize optionslen properly before copying data into options, however in the GRE ERSPAN code a partial update is done, preventing the use of the helper function.

Before this change the handling of ERSPAN traffic in GRE tunnels would cause a kernel panic when the kernel is compiled with GCC 15+ and having FORTIFYSOURCE configured:

memcpy: detected buffer overflow: 4 byte write of buffer size 0

Call Trace: <IRQ> fortifypanic+0xd/0xf erspanrcv.cold+0x68/0x83 ? iprouteinputslow+0x816/0x9d0 grercv+0x1b2/0x1c0 grercv+0x8e/0x100 ? rawv4input+0x2a0/0x2b0 ipprotocoldeliverrcu+0x1ea/0x210 iplocaldeliverfinish+0x86/0x110 iplocaldeliver+0x65/0x110 ? iprcvfinishcore+0xd6/0x360 iprcv+0x186/0x1a0

Reported-at: https://launchpad.net/bugs/2129580

ethtool: Avoid overflowing userspace buffer on stats query

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

scsi: qla2xxx: Fix improper freeing of purex item

In qla2xxxprocesspurlsiocb(), an item is allocated via qla27xxcopymultiplepkt(), which internally calls qla24xxallocpurexitem().

The qla24xxallocpurexitem() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().

An error handling path in qla2xxxprocesspurlsiocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.

Fix this by using the correct deallocation function, qla24xxfreepurexitem(), which properly handles both dynamically allocated and pre-allocated items.

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

platform/x86: intel: punitipc: fix memory corruption

This passes the address of the pointer "&punitipcdev" when the intent was to pass the pointer itself "punitipcdev" (without the ampersand). This means that the:

complete(&ipcdev->cmdcomplete);

in intelpunitioc() will write to a wrong memory address corrupting it.

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

iouring/net: ensure vectored buffer node import is tied to notification

When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification iokiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct iokiocb for the vectored buffer import.

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

ksmbd: close accepted socket when per-IP limit rejects connection

When the per-IP connection limit is exceeded in ksmbdkthreadfn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS.

Release clientsk before continuing.

This bug was found with ZeroPath.

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

net: bridge: fix use-after-free due to MST port state bypass

syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot.

[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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

crypto: qat - fix out-of-bounds read

When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read.

Fix by doing the copy first and then update the keylen.

This is to fix the following warning reported by KASAN:

[ 138.150574] BUG: KASAN: global-out-of-bounds in qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgrtest/2340

[ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgrtest Not tainted 6.2.0-rc1+ #45 [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022 [ 138.150663] Call Trace: [ 138.150668] <TASK> [ 138.150922] kasancheckrange+0x13a/0x1c0 [ 138.150931] memcpy+0x1f/0x60 [ 138.150940] qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.151006] qatalgskcipherinitsessions+0xc1/0x240 [intelqat] [ 138.151073] cryptoskciphersetkey+0x82/0x160 [ 138.151085] ? preparekeybuf+0xa2/0xd0 [ 138.151095] testskcipherveccfg+0x2b8/0x800

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

RDMA/irdma: Fix data race on CQP request done

KCSAN detects a data race on cqprequest->requestdone memory location which is accessed locklessly in irdmahandlecqpop while being updated in irdmacqpcehandler.

Annotate lockless intent with READONCE/WRITEONCE to avoid any compiler optimizations like load fusing and/or KCSAN warning.

[222808.417128] BUG: KCSAN: data-race in irdmacqpcehandler [irdma] / irdmawaitevent [irdma]

[222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5: [222808.417610] irdmacqpcehandler+0x21e/0x270 [irdma] [222808.417725] cqpcomplworker+0x1b/0x20 [irdma] [222808.417827] processonework+0x4d1/0xa40 [222808.417835] workerthread+0x319/0x700 [222808.417842] kthread+0x180/0x1b0 [222808.417852] retfromfork+0x22/0x30

[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1: [222808.417995] irdmawaitevent+0x1e2/0x2c0 [irdma] [222808.418099] irdmahandlecqpop+0xae/0x170 [irdma] [222808.418202] irdmacqpcqdestroycmd+0x70/0x90 [irdma] [222808.418308] irdmapudadelersrc+0x46d/0x4d0 [irdma] [222808.418411] irdmartdeinithw+0x179/0x1d0 [irdma] [222808.418514] irdmaibdeallocdevice+0x11/0x40 [irdma] [222808.418618] ibdeallocdevice+0x2a/0x120 [ibcore] [222808.418823] ibunregisterdevice+0xde/0x100 [ibcore] [222808.418981] ibunregisterdevice+0x22/0x40 [ibcore] [222808.419142] irdmaibunregisterdevice+0x70/0x90 [irdma] [222808.419248] i40iwclose+0x6f/0xc0 [irdma] [222808.419352] i40eclientdeviceunregister+0x14a/0x180 [i40e] [222808.419450] i40iwremove+0x21/0x30 [irdma] [222808.419554] auxiliarybusremove+0x31/0x50 [222808.419563] deviceremove+0x69/0xb0 [222808.419572] devicereleasedriverinternal+0x293/0x360 [222808.419582] driverdetach+0x7c/0xf0 [222808.419592] busremovedriver+0x8c/0x150 [222808.419600] driverunregister+0x45/0x70 [222808.419610] auxiliarydriverunregister+0x16/0x30 [222808.419618] irdmaexitmodule+0x18/0x1e [irdma] [222808.419733] dosysdeletemodule.constprop.0+0x1e2/0x310 [222808.419745] x64sysdeletemodule+0x1b/0x30 [222808.419755] dosyscall64+0x39/0x90 [222808.419763] entrySYSCALL64afterhwframe+0x63/0xcd

[222808.419829] value changed: 0x01 -> 0x03

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

cifs: fix potential oops in cifsoplockbreak

With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplockresponse(), this can mean that an unmount (killsb) can occur just before we were checking if the tcon->ses is valid. See below:

[Fri Aug 4 04:12:50 2023] RIP: 0010:cifsoplockbreak+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39 [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206 [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009 [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188 [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900 [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138 [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000 [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000 [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0 [Fri Aug 4 04:12:50 2023] Call Trace: [Fri Aug 4 04:12:50 2023] <TASK> [Fri Aug 4 04:12:50 2023] processonework+0x225/0x3d0 [Fri Aug 4 04:12:50 2023] workerthread+0x4d/0x3e0 [Fri Aug 4 04:12:50 2023] ? processonework+0x3d0/0x3d0 [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150 [Fri Aug 4 04:12:50 2023] ? setkthreadstruct+0x50/0x50 [Fri Aug 4 04:12:50 2023] retfromfork+0x22/0x30 [Fri Aug 4 04:12:50 2023] </TASK>

To fix this change the ordering of the checks before sending the oplockresponse to first check if the openFileList is empty.

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

drm/ttm: Don't leak a resource on eviction error

On eviction errors other than -EMULTIHOP we were leaking a resource. Fix.

v2: - Avoid yet another goto (Andi Shyti)

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

serial: 8250: Fix oops for port->pm on uartchangepm()

Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uarthangup() calling uartchangepm().

Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250pm() will call port->pm() instead of serial8250dopm().

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

tracing/userevents: Ensure write index cannot be negative

The write index indicates which event the data is for and accesses a per-file array. The index is passed by user processes during write() calls as the first 4 bytes. Ensure that it cannot be negative by returning -EINVAL to prevent out of bounds accesses.

Update ftrace self-test to ensure this occurs properly.

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

hfs/hfsplus: avoid WARNON() for sanity check, use proper error handling

Commit 55d1cbbbb29e ("hfs/hfsplus: use WARNON for sanity check") fixed a build warning by turning a comment into a WARNON(), but it turns out that syzbot then complains because it can trigger said warning with a corrupted hfs image.

The warning actually does warn about a bad situation, but we are much better off just handling it as the error it is. So rather than warn about us doing bad things, stop doing the bad things and return -EIO.

While at it, also fix a memory leak that was introduced by an earlier fix for a similar syzbot warning situation, and add a check for one case that historically wasn't handled at all (ie neither comment nor subsequent WARNON).

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

blk-cgroup: hold queuelock when removing blkg->qnode

When blkg is removed from q->blkglist from blkgfreeworkfn(), queuelock has to be held, otherwise, all kinds of bugs(list corruption, hard lockup, ..) can be triggered from blkgdestroyall().

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

mptcp: fix NULL pointer dereference on fastopen early fallback

In case of early fallback to TCP, subflowsynrecvsock() deletes the subflow context before returning the newly allocated sock to the caller.

The fastopen path does not cope with the above unconditionally dereferencing the subflow context.

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

opp: Fix use-after-free in lazyopptables after probe deferral

When devpmoppoffindiccpaths() in allocateopptable() returns -EPROBEDEFER, the opptable is freed again, to wait until all the interconnect paths are available.

However, if the OPP table is using required-opps then it may already have been added to the global lazyopptables list. The error path does not remove the opptable from the list again.

This can cause crashes later when the provider of the required-opps is added, since we will iterate over OPP tables that have already been freed. E.g.:

Unable to handle kernel NULL pointer dereference when read CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 PC is at ofaddopptablev2 (include/linux/of.h:949 drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 drivers/opp/of.c:1032) -> lazylinkrequiredopptable()

Fix this by calling ofclearopptable() to remove the opptable from the list and clear other allocated resources. While at it, also add the missing mutexdestroy() calls in the error path.

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

RDMA/rxe: Fix NULL-ptr-deref in rxeqpdocleanup() when socket create failed

There is a null-ptr-deref when mount.cifs over rdma:

BUG: KASAN: null-ptr-deref in rxeqpdocleanup+0x2f3/0x360 [rdmarxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046

CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: <TASK> dumpstacklvl+0x34/0x44 kasanreport+0xad/0x130 rxeqpdocleanup+0x2f3/0x360 [rdmarxe] executeinprocesscontext+0x25/0x90 rxecleanup+0x101/0x1d0 [rdmarxe] rxecreateqp+0x16a/0x180 [rdmarxe] createqp.part.0+0x27d/0x340 ibcreateqpkernel+0x73/0x160 rdmacreateqp+0x100/0x230 smbdgetconnection+0x752/0x20f0 smbdgetconnection+0x21/0x40 cifsgettcpsession+0x8ef/0xda0 mountgetconns+0x60/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The root cause of the issue is the socket create failed in rxeqpinitreq().

So move the reset rxeqpdocleanup() after the NULL ptr check.

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

staging: media: tegra-video: fix devicenode use after free

At probe time this code path is followed:

tegracsiinit tegracsichannelsalloc foreachchildofnode(node, channel) -- iterates over channels automatically gets 'channel' tegracsichannelalloc() saves into chan->ofnode a pointer to the channel OF node automatically gets and puts 'channel' now the node saved in chan->ofnode has refcount 0, can disappear tegracsichannelsinit iterates over channels tegracsichannelinit -- uses chan->ofnode

After that, chan->ofnode keeps storing the node until the device is removed.

ofnodeget() the node and ofnodeput() it during teardown to avoid any risk.

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.

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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

bpf: Check skb->transportheader is set in bpfskbcheckmtu

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

padata: avoid UAF for reorderwork

Although the previous patch can avoid ps and ps UAF for doserial, it can not avoid potential UAF issue for reorderwork. This issue can happen just as below:

cryptorequest cryptorequest cryptodelalg padatadoserial ... padatareorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }

padatadoserial // new request added listadd // sees the new request queuework(reorderwork) padatareorder queueworkon(squeue->work) ...

<kworker context> padataserialworker // completes new request, // no more outstanding // requests

cryptodelalg // free pd

<kworker context> invokepadatareorder // UAF of pd

To avoid UAF for 'reorderwork', get 'pd' ref before put 'reorderwork' into the 'serialwq' and put 'pd' ref until the 'serialwq' finish.

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

net/mlx5e: Check for NOTREADY flag state after locking

Currently the check for NOTREADY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unreadyflows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplinkpriv->unreadyflowslock mutex.

[0]: [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1 [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP: 0010:mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] Call Trace: [44376.406651] <TASK> [44376.406939] ? dieaddr+0x33/0x90 [44376.407311] ? excgeneralprotection+0x192/0x390 [44376.407795] ? asmexcgeneralprotection+0x22/0x30 [44376.408292] ? mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.408876] mlx5etcdelfdbpeerflow+0xbc/0xe0 [mlx5core] [44376.409482] mlx5etcdelflow+0x42/0x210 [mlx5core] [44376.410055] mlx5eflowput+0x25/0x50 [mlx5core] [44376.410529] mlx5edeleteflower+0x24b/0x350 [mlx5core] [44376.411043] tcsetupcbreoffload+0x22/0x80 [44376.411462] flreoffload+0x261/0x2f0 [clsflower] [44376.411907] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.412481] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.413044] tcfblockplaybackoffloads+0x76/0x170 [44376.413497] tcfblockunbind+0x7b/0xd0 [44376.413881] tcfblocksetup+0x17d/0x1c0 [44376.414269] tcfblockoffloadcmd.isra.0+0xf1/0x130 [44376.414725] tcfblockoffloadunbind+0x43/0x70 [44376.415153] tcfblockput+0x82/0x150 [44376.415532] ingressdestroy+0x22/0x30 [schingress] [44376.415986] qdiscdestroy+0x3b/0xd0 [44376.416343] qdiscgraft+0x4d0/0x620 [44376.416706] tcgetqdisc+0x1c9/0x3b0 [44376.417074] rtnetlinkrcvmsg+0x29c/0x390 [44376.419978] ? repmovsalternative+0x3a/0xa0 [44376.420399] ? rtnlcalcit.isra.0+0x120/0x120 [44376.420813] netlinkrcvskb+0x54/0x100 [44376.421192] netlinkunicast+0x1f6/0x2c0 [44376.421573] netlinksendmsg+0x232/0x4a0 [44376.421980] socksendmsg+0x38/0x60 [44376.422328] syssendmsg+0x1d0/0x1e0 [44376.422709] ? copymsghdrfromuser+0x6d/0xa0 [44376.423127] syssendmsg+0x80/0xc0 [44376.423495] ? sysrecvmsg+0x8b/0xc0 [44376.423869] syssendmsg+0x51/0x90 [44376.424226] dosyscall64+0x3d/0x90 [44376.424587] entrySYSCALL64afterhwframe+0x46/0xb0 [44376.425046] RIP: 0033:0x7f045134f887 [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated---