bpf: Fix helper writes to read-only maps
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Make it so that a waiting process can be aborted
When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters.
However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made.
Fix this so that the call can at least be aborted without failing on EBUSY. We have to be careful here as sendmsg() mustn't be allowed to start the call timer if the call doesn't yet have a connection assigned as an oops may follow shortly thereafter.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix mbss changed flags corruption on 32 bit systems
On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using oreachsetbit(bit, &bits, sizeof(changed) BITSPERBYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.
Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.
Call Trace: ? showregs+0x54/0x58 ? warn+0x6b/0xd4 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? reportbug+0x113/0x150 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x44 ? excinvalidop+0x18/0x50 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? ieee80211meshwork+0xff/0x260 [mac80211] ? cfg80211wiphywork+0x72/0x98 [cfg80211] ? processonework+0xf1/0x1fc ? workerthread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? moddelayedworkon+0x4c/0x4c ? kthreadcompleteandexit+0x14/0x14 ? retfromfork+0x24/0x38 ? kthreadcompleteandexit+0x14/0x14 ? retfromforkasm+0xf/0x14 ? entryINT8032+0xf0/0xf0
[restore no-op path for no changes]
ALSA: seq: oss: Fix races at processing SysEx messages
bpf: Defer work in bpftimercancelandfree
Bluetooth: hciconn: Use disabledelayedworksync
Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcommsockalloc()
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: extend RCU protection in igmp6send()
igmp6send() can be called without RTNL or RCU being held.
Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.
Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFPKERNEL allocations which can sleep.
Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.
btrfs: don't check PageError in extentwritepage
In the Linux kernel, the following vulnerability has been resolved:
iomap: iomap: fix memory corruption when recording errors during writeback
Every now and then I see this crash on arm64:
Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dmthinpool dmpersistentdata XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ec/0x590 [xfs] (fs/xfs/xfstransbuf.c:296). dmbioprison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfsimaplookup: xfsiallocreadagi() returned error -5, agno 0 dmbufio dmlogwrites xfs nftchainnat xtREDIRECT nfnat nfconntrack nfdefragipv6 nfdefragipv4 ip6tREJECT potentially unexpected fatal signal 6. nfrejectipv6 potentially unexpected fatal signal 6. iptREJECT nfrejectipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsecgsskrb5 authrpcgss xttcpudp ipsethaship ipsethashnet xtset nftcompat ipsethashmac ipset nftables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) iptables pc : 000003fd6d7df200 xtables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wbworkfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseqset+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : filemapsetwberr+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseqset+0x1c/0x100 filemapsetwberr+0x24/0xe0 iomapdowritepage+0x5e4/0xd5c writecachepages+0x208/0x674 iomapwritepages+0x34/0x60 xfsvmwritepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: lock against ->sock changing during sysfs read
->sock can be set to NULL asynchronously unless ->recvmutex is held. So it is important to hold that mutex. Otherwise a sysfs read can trigger an oops. Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before handling sysfs reads") appears to attempt to fix this problem, but it only narrows the race window.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: initialize closework early to avoid warning
We encountered a warning that closework was canceled before initialization.
WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 flushwork+0x19e/0x1b0 Workqueue: events smclgrterminatework [smc] RIP: 0010:flushwork+0x19e/0x1b0 Call Trace: ? wakeupcommon+0x7a/0x190 ? workbusy+0x80/0x80 cancelworktimer+0xe3/0x160 smcclosecancelwork+0x1a/0x70 [smc] smccloseactiveabort+0x207/0x360 [smc] smclgrterminate.part.38+0xc8/0x180 [smc] processonework+0x19e/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x117/0x130 ? kthreadcancelwork+0x50/0x50 retfromfork+0x22/0x30
This is because when smcclosecancelwork is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->closework is flushed before initialization, resulting in WARNON(!work->func).
smclgrterminate | smcconnect{rdma|ism} ------------------------------------------------------------- | smcconncreate | \- smclgrregisterconn for conn in lgr->connsall | \- smcconnkill | \- smccloseactiveabort | \- smcclosecancelwork | \- cancelworksync | \- flushwork | (closework) | | smccloseinit | \- INITWORK(&closework)
So fix this by initializing closework before establishing the connection.
drm/amd/display: Skip on writeback when it's not applicable
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in smb2queryinfocompound()
The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,maxchannels=2,vers=3.1.1,mfsymlinks,noperm'
BUG: KASAN: slab-use-after-free in smb2queryinfocompound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfsio/27534
CPU: 0 PID: 27534 Comm: xfsio Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dumpstacklvl+0x4a/0x80 printreport+0xcf/0x650 ? srsoaliasreturnthunk+0x5/0x7f ? srsoaliasreturnthunk+0x5/0x7f ? physaddr+0x46/0x90 kasanreport+0xda/0x110 ? smb2queryinfocompound+0x423/0x6d0 [cifs] ? smb2queryinfocompound+0x423/0x6d0 [cifs] smb2queryinfocompound+0x423/0x6d0 [cifs] ? pfxsmb2queryinfocompound+0x10/0x10 [cifs] ? srsoaliasreturnthunk+0x5/0x7f ? stackdepotsave+0x39/0x480 ? kasansavestack+0x33/0x60 ? kasansettrack+0x25/0x30 ? kasanslabfree+0x126/0x170 smb2queryfs+0xc2/0x2c0 [cifs] ? pfxsmb2queryfs+0x10/0x10 [cifs] ? pfxlockacquire+0x10/0x10 smb311queryfs+0x210/0x220 [cifs] ? pfxsmb311queryfs+0x10/0x10 [cifs] ? srsoaliasreturnthunk+0x5/0x7f ? lockacquire+0x480/0x26c0 ? lockrelease+0x1ed/0x640 ? srsoaliasreturnthunk+0x5/0x7f ? dorawspinunlock+0x9b/0x100 cifsstatfs+0x18c/0x4b0 [cifs] statfsbydentry+0x9b/0xf0 fdstatfs+0x4e/0xb0 dosysfstatfs+0x7f/0xe0 ? pfxdosysfstatfs+0x10/0x10 ? srsoaliasreturnthunk+0x5/0x7f ? lockdephardirqsonprepare+0x136/0x200 ? srsoaliasreturnthunk+0x5/0x7f dosyscall64+0x3f/0x90 entrySYSCALL64afterhwframe+0x6e/0xd8
Allocated by task 27534: kasansavestack+0x33/0x60 kasansettrack+0x25/0x30 kasankmalloc+0x8f/0xa0 opencacheddir+0x71b/0x1240 [cifs] smb2queryinfocompound+0x5c3/0x6d0 [cifs] smb2queryfs+0xc2/0x2c0 [cifs] smb311queryfs+0x210/0x220 [cifs] cifsstatfs+0x18c/0x4b0 [cifs] statfsbydentry+0x9b/0xf0 fdstatfs+0x4e/0xb0 dosysfstatfs+0x7f/0xe0 dosyscall64+0x3f/0x90 entrySYSCALL64afterhwframe+0x6e/0xd8
Freed by task 27534: kasansavestack+0x33/0x60 kasansettrack+0x25/0x30 kasansavefreeinfo+0x2b/0x50 kasanslabfree+0x126/0x170 slabfreefreelisthook+0xd0/0x1e0 kmemcachefree+0x9d/0x1b0 opencacheddir+0xff5/0x1240 [cifs] smb2queryinfocompound+0x5c3/0x6d0 [cifs] smb2queryfs+0xc2/0x2c0 [cifs]
This is a race between opencacheddir() and cacheddirleasebreak() where the cache entry for the open directory handle receives a lease break while creating it. And before returning from opencacheddir(), we put the last reference of the new @cfid because of !@cfid->haslease.
Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids
CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ...
To fix both, in opencacheddir() ensure that @cfid->haslease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid. And, if open failed for some reason, re-check @cfid->haslease to decide whether or not put lease reference.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nfbridgeinfo
An skb can be added to a neigh->arpqueue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arpqueue of the bridge.
As skb->dev can be reset back to nfbridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neighflushdev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:
arpprocess neighupdate skb = skbdequeue(&neigh->arpqueue) neighresolveoutput(..., skb) ... brnfdevxmit brnfpreroutingfinishbridgeslow skb->dev = nfbridge->physindev brhandleframefinish
Let's use plain ifindex instead of netdevice link. To peek into the original netdevice we will use devgetbyindexrcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.
ax25: Fix netdev refcount issue
In the Linux kernel, the following vulnerability has been resolved:
smb3: missing lock when picking channel
Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index.
Addresses-Coverity: 1582039 ("Data race condition (MISSINGLOCK)")
btrfs: make sure that WRITTEN is set on all metadata blocks
f2fs: fix to truncate meta inode pages forcely
i40e: Do not allow untrusted VF to remove administratively set MAC
afunix: Don't leave consecutive consumed OOB skbs.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix "KASAN: slab-use-after-free Read in ibregisterdevice" problem
Call Trace:
dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 fortifystrlen include/linux/fortify-string.h:268 [inline] getkobjpathlength lib/kobject.c:118 [inline] kobjectgetpath+0x3f/0x2a0 lib/kobject.c:158 kobjectueventenv+0x289/0x1870 lib/kobjectuevent.c:545 ibregisterdevice drivers/infiniband/core/device.c:1472 [inline] ibregisterdevice+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxeregisterdevice+0x275/0x320 drivers/infiniband/sw/rxe/rxeverbs.c:1552 rxenetadd+0x8e/0xe0 drivers/infiniband/sw/rxe/rxenet.c:550 rxenewlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldevnewlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdmanlrcvmsg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdmanlrcvskb.constprop.0.isra.0+0x2e5/0x450 netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] netlinkunicast+0x53a/0x7f0 net/netlink/afnetlink.c:1339 netlinksendmsg+0x8d1/0xdd0 net/netlink/afnetlink.c:1883 socksendmsgnosec net/socket.c:712 [inline] socksendmsg net/socket.c:727 [inline] syssendmsg+0xa95/0xc70 net/socket.c:2566 syssendmsg+0x134/0x1d0 net/socket.c:2620 syssendmsg+0x16d/0x220 net/socket.c:2652 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x260 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.
The root cause is: the function ibdevicerename() renames the name with lock. But in the function kobjectuevent(), this name is accessed without lock protection at the same time.
The solution is to add the lock protection when this name is accessed in the function kobjectuevent().
block: RCU protect disk->convzonesbitmap
drm/msm/dpu: Add mutex lock in control vblank irq
drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleupreq()
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: unquiesce adminq before destroy it
Kernel will hang on destroy adminq while we create ctrl failed, such as following calltrace:
PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blkmqfreezequeuewait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blkfreezequeue at ffffffff82a4113a #4 [ff61d23de260fc90] blkcleanupqueue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvmerdmadestroyadminqueue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvmerdmasetupctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvmerdmacreatectrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmfdevwrite at ffffffffc024f362 #9 [ff61d23de260fe38] vfswrite at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIGRAX: 0000000000000001 CS: 0033 SS: 002b
This due to we have quiesced admiq before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blkmqfreezequeuewait() forever. Here try to reuse nvmerdmateardownadminqueue() to fix this issue and simplify the code.
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices
Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.
drm/msm: Fix another leak in the submit error path
In the Linux kernel, the following vulnerability has been resolved:
net: reenable NETIFFIPV6CSUM offload for BIG TCP packets
The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6CSUM, based on the definition of that feature in skbuff.h:
- %NETIFFIPV6CSUM - Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIFFHWCSUM also set. This feature is being DEPRECATED (see below).
The change causes skbwarnbadoffload to fire for BIG TCP packets.
[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbadoffload+0xc4/0xe0
[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] qdiscrun+0x388/0x620
BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices.
For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.
ipv6hashopoptjumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from firstremotercu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlansnoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlanencapbypass+0x209/0x240 encapbypassiflocal+0xb1/0x100 vxlanxmitone+0x1375/0x17e0 vxlanxmit+0x6b4/0x15f0 devhardstartxmit+0x5d/0x1c0 devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 socksendmsg+0x38/0x70 syssendto+0x126/0x180 x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q