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

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:

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:

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:

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:

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:

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:

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:

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:

mt76: mt7615: Fix memory leak in mt7615mcuwtblstaadd()

In mt7615mcuwtblstaadd(), an skb sskb is allocated. If the subsequent call to mt76connacmcuallocwtblreq() fails, the function returns an error without freeing sskb, leading to a memory leak.

Fix this by calling devkfreeskb() on sskb in the error handling path to ensure it is properly released.

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:

drm/sysfb: Do not dereference NULL pointer in plane reset

The plane state in drmgemresetshadowplane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.

v2: - fix typo in commit description (Javier)

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

mlx5: Fix default values in create CQ

Currently, CQs without a completion function are assigned the mlx5addcqtotasklet function by default. This is problematic since only user CQs created through the mlx5ib driver are intended to use this function.

Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5cqarm. However, the default CQ creation flow leaves a valid value in the CQ's armdb field, allowing FW to send interrupts to polling-only CQs in certain corner cases.

These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.

Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.

This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.

Callers of mlx5corecreatecq are responsible for changing the completion function and arming the CQ per their needs.

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

net: ethernet: ti: netcp: Standardize knavdmaopenchannel to return NULL on error

Make knavdmaopenchannel consistently return NULL on error instead of ERRPTR. Currently the header include/linux/soc/ti/knavdma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERRPTR on failure, causing inconsistency in the users. This results in a crash in netcpfreenavigatorresources as followed (trimmed):

Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] pgd=80000800207003, pmd=82ffda003, pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knavdmaclosechannel+0x30/0x19c LR is at netcpfreenavigatorresources+0x2c/0x28c

[... TRIM...]

Call trace: knavdmaclosechannel from netcpfreenavigatorresources+0x2c/0x28c netcpfreenavigatorresources from netcpndoopen+0x430/0x46c netcpndoopen from devopen+0x114/0x29c devopen from devchangeflags+0x190/0x208 devchangeflags from netifchangeflags+0x1c/0x58 netifchangeflags from devchangeflags+0x38/0xa0 devchangeflags from ipautoconfig+0x2c4/0x11f0 ipautoconfig from dooneinitcall+0x58/0x200 dooneinitcall from kernelinitfreeable+0x1cc/0x238 kernelinitfreeable from kernelinit+0x1c/0x12c kernelinit from retfromfork+0x14/0x38 [... TRIM...]

Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcpcore.c so the impact is limited.

Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcpcore: return error while dma channel open issue"), but provides a less error prone implementation.

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:

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:

accel/amdxdna: Fix an integer overflow in aie2queryctxstatusarray()

The unpublished smatch static checker reported a warning.

drivers/accel/amdxdna/aie2pci.c:904 aie2queryctxstatusarray() warn: potential user controlled sizeof overflow 'args->numelement args->elementsize' '1-u32max(user) 1-u32max(user)'

Even this will not cause a real issue, it is better to put a reasonable limitation for elementsize and numelement. Add condition to make sure the input elementsize <= 4K and numelement <= 1K.

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

macintosh/machid: fix race condition in machidtoggleemumouse

The following warning appears when running syzkaller, and this issue also exists in the mainline code.

------------[ cut here ]------------ listadd double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/listdebug.c:35 listaddvalidorreport+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:listaddvalidorreport+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> inputregisterhandler+0xb3/0x210 machidstartemulation+0x1c5/0x290 machidtoggleemumouse+0x20a/0x240 procsyscallhandler+0x4c2/0x6e0 newsyncwrite+0x1b1/0x2d0 vfswrite+0x709/0x950 ksyswrite+0x12a/0x250 dosyscall64+0x5a/0x110 entrySYSCALL64afterhwframe+0x78/0xe2

The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in machidtoggleemumouse(). Both processes read oldval=0, then both try to register the input handler, leading to a double listadd of the same handler.

CPU0 CPU1 ------------------------- ------------------------- vfswrite() //write 1 vfswrite() //write 1 procsyswrite() procsyswrite() machidtoggleemumouse() machidtoggleemumouse() oldval = valp // oldval=0 oldval = valp // oldval=0 mutexlockkillable() procdointvec() // valp=1 machidstartemulation() inputregisterhandler() mutexunlock() mutexlockkillable() procdointvec() machidstartemulation() inputregisterhandler() //Trigger Warning mutexunlock()

Fix this by moving the oldval read inside the mutex lock region.

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.

ima: Handle error code returned by imafilterrulematch()

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

bonding: annotate data-races around slave->lastrx

fbdev: smscufx: properly copy ioctl memory to kernelspace

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