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

net: mana: Fix race on per-CQ variable napi workdone

After calling napicompletedone(), the NAPIFSTATESCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->workdone. If the other thread (for example, from busypoll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic.

To fix this issue, save the per-CQ workdone variable in a local variable before napicompletedone(), so it won't be corrupted by a possible concurrent thread after napicompletedone().

Also, add a flag bit to advertise to the NIC firmware: the NAPI workdone variable race is fixed, so the driver is able to reliably support features like busypoll.

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

nvme: fix SRCU protection of nvmenshead list

Walking the nvmenshead siblings list is protected by the head's srcu in nvmensheadsubmitbio() but not nvmempathrevalidatepaths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees.

Hold the head's srcu lock in nvmempathrevalidatepaths() and synchronize with the srcu, not the global RCU, in nvmensremove().

Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != getcapacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic).

[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x8664 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvmescanwork [nvmecore] [37314.299783] RIP: 0010:nvmempathrevalidatepaths+0x26/0xb0 [nvmecore] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvmeupdatensinfo+0x1ac/0x250 [nvmecore] [37315.892075] nvmevalidateorallocns+0x2ff/0xa00 [nvmecore] [37315.961871] ? blkmqfreerequest+0x6b/0x90 [37316.015021] nvmescanwork+0x151/0x240 [nvmecore] [37316.073371] processonework+0x1a7/0x360 [37316.121318] ? createworker+0x1a0/0x1a0 [37316.168227] workerthread+0x30/0x390 [37316.212024] ? createworker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? setkthreadstruct+0x50/0x50 [37316.347590] retfromfork+0x35/0x40 [37316.390360] Modules linked in: nvmerdma nvmetcp(X) nvmefabrics nvmecore netconsole iscsitcp libiscsitcp dmqueuelength dmservicetime nfconntracknetlink brnetfilter bridge stp llc overlay nftchainnat iptMASQUERADE nfnat xtaddrtype xtCT nftcounter xtstate xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment xtmultiport nftcompat nftables libcrc32c nfnetlink dmmultipath tg3 rpcrdma sunrpc rdmaucm ibsrpt ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm intelraplmsr iTCOwdt iTCOvendorsupport dcdbas intelraplcommon sbedac x86pkgtempthermal intelpowerclamp coretemp kvmintel ipmissif kvm irqbypass crct10difpclmul crc32pclmul mlx5ib ghashclmulniintel ibuverbs rapl intelcstate inteluncore ibcore ipmisi joydev meime pcspkr ipmidevintf mei lpcich wmi ipmimsghandler acpipowermeter ex ---truncated---

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

skmsg: pass gfp argument to allocskmsg()

syzbot found that allocskmsg() could be called from a non sleepable context. skpsockverdictrecv() uses rcureadlock() protection.

We need the callers to pass a gfpt argument to avoid issues.

syzbot report was:

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 3613, name: syz-executor414 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 mightresched+0x538/0x6a0 kernel/sched/core.c:9877 mightalloc include/linux/sched/mm.h:274 [inline] slabpreallochook mm/slab.h:700 [inline] slaballocnode mm/slub.c:3162 [inline] slaballoc mm/slub.c:3256 [inline] kmemcachealloctrace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] allocskmsg net/core/skmsg.c:507 [inline] skpsockskbingressself+0x5c/0x330 net/core/skmsg.c:600 skpsockverdictapply+0x395/0x440 net/core/skmsg.c:1014 skpsockverdictrecv+0x34d/0x560 net/core/skmsg.c:1201 tcpreadskb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcprcvestablished+0x129d/0x1a10 net/ipv4/tcpinput.c:5971 tcpv4dorcv+0x479/0xac0 net/ipv4/tcpipv4.c:1681 skbacklogrcv include/net/sock.h:1109 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2906 releasesock+0x5d/0x1c0 net/core/sock.c:3462 tcpsendmsg+0x36/0x40 net/ipv4/tcp.c:1483 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x46d/0x5f0 net/socket.c:2117 dosyssendto net/socket.c:2129 [inline] sesyssendto net/socket.c:2125 [inline] x64syssendto+0xda/0xf0 net/socket.c:2125 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

A deouble-free flaw in the Linux Kernel Intel GVT-g graphics driver found. The problem happens when some system resource on high cost. One way to trigger is to make dma high load. When it gets into the situation when function intelgvtdmamapguestpage failed, the flaw being triggered.

Reference: https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz@163.com/

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

ceph: avoid putting the realm twice when decoding snaps fails

When decoding the snaps fails it maybe leaving the 'firstrealm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUGON, etc issues.

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

s390/qeth: fix use-after-free in hsci

KASAN found that addr was dereferenced after br2deveventwork was freed.

================================================================== BUG: KASAN: use-after-free in qethl2br2devworker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000event qethl2br2devworker Call Trace: [<000000016944d4ce>] dumpstacklvl+0xc6/0xf8 [<000000016942cd9c>] printaddressdescription.constprop.0+0x34/0x2a0 [<000000016942d118>] printreport+0x110/0x1f8 [<0000000167a7bd04>] kasanreport+0xfc/0x128 [<000000016938d79a>] qethl2br2devworker+0x5ba/0x6b0 [<00000001673edd1e>] processonework+0x76e/0x1128 [<00000001673ee85c>] workerthread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] retfromfork+0x8a/0xe8 [<00000001694711da>] retfromfork+0xa/0x40 Allocated by task 108338: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasankmalloc+0xa0/0xc0 qethl2switchdevevent+0x25a/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Freed by task 540: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasansavefreeinfo+0x4c/0x68 kasanslabfree+0x14e/0x1a8 kasanslabfree+0x24/0x30 kmemcachefree+0x168/0x338 qethl2br2devworker+0x154/0x6b0 processonework+0x76e/0x1128 workerthread+0x184/0x1098 kthread+0x26a/0x310 retfromfork+0x8a/0xe8 retfromfork+0xa/0x40 Last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 insertwork+0x56/0x2e8 queuework+0x4ce/0xd10 queueworkon+0xf4/0x100 qethl2switchdevevent+0x520/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Second to last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 kvfreecallrcu+0xb2/0x760 kernfsunlinkopenfile+0x348/0x430 kernfsfoprelease+0xc2/0x320 fput+0x1ae/0x768 taskworkrun+0x1bc/0x298 exittousermodeprepare+0x1a0/0x1a8 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated---

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

ravb: Fix potential use-after-free in ravbrxgbeth()

The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.

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

tipc: re-fetch skb cb after tipcmsgvalidate

As the call trace shows, the original skb was freed in tipcmsgvalidate(), and dereferencing the old skb cb would cause an use-after-free crash.

BUG: KASAN: use-after-free in tipccryptorcvcomplete+0x1835/0x2240 [tipc] Call Trace: <IRQ> tipccryptorcvcomplete+0x1835/0x2240 [tipc] tipccryptorcv+0xd32/0x1ec0 [tipc] tipcrcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmemcacheallocnode+0x158/0x4d0 allocskb+0x1c1/0x270 tipcbufacquire+0x1e/0xe0 [tipc] tipcmsgcreate+0x33/0x1c0 [tipc] tipclinkbuildprotomsg+0x38a/0x2100 [tipc] tipclinktimeout+0x8b8/0xef0 [tipc] tipcnodetimeout+0x2a1/0x960 [tipc] calltimerfn+0x2d/0x1c0 ... Freed by task 47078: tipcmsgvalidate+0x7b/0x440 [tipc] tipccryptorcvcomplete+0x4b5/0x2240 [tipc] tipccryptorcv+0xd32/0x1ec0 [tipc] tipcrcv+0x744/0x1150 [tipc]

This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipcmsgvalidate().

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

powerpc/bpf/32: Fix Oops on tail call tests

testbpf tail call tests end up as:

testbpf: #0 Tail call leaf jited:1 85 PASS testbpf: #1 Tail call 2 jited:1 111 PASS testbpf: #2 Tail call 3 jited:1 145 PASS testbpf: #3 Tail call 4 jited:1 170 PASS testbpf: #4 Tail call load/store leaf jited:1 190 PASS testbpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGESIZE=4K MMU=Hash PowerMac Modules linked in: testbpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] runone+0xec/0x264 [testbpf] Call Trace: [f1b4dfe0] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]---

This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee7b690 ("bpf, tests: Add load store test case for tail call")

This happens because tail call is done to a BPF prog with a different stackdepth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes.

This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different.

Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later.

Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit.

With the fix, tail call tests are now successfull:

testbpf: #0 Tail call leaf jited:1 53 PASS testbpf: #1 Tail call 2 jited:1 115 PASS testbpf: #2 Tail call 3 jited:1 154 PASS testbpf: #3 Tail call 4 jited:1 165 PASS testbpf: #4 Tail call load/store leaf jited:1 101 PASS testbpf: #5 Tail call load/store jited:1 141 PASS testbpf: #6 Tail call error path, max count reached jited:1 994 PASS testbpf: #7 Tail call count preserved across function calls jited:1 140975 PASS testbpf: #8 Tail call error path, NULL target jited:1 110 PASS testbpf: #9 Tail call error path, index out of range jited:1 69 PASS testbpf: testtailcalls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed]

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

media: atomisp: prevent integer overflow in shcsssetblackframe()

The "height" and "width" values come from the user so the "height width" multiplication can overflow.

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

x86/tdx: Panic on bad configs that #VE on "private" memory access

All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically deliver a virtualization exception (#VE) on any access to private memory.

But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTRSEPTVEDISABLE. The guest has no way to set this attribute, but it can check it.

Ensure ATTRSEPTVEDISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate.

There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access.

[ dhansen: Rewrite changelog and rebase on new tdxparsetdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]

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

net: hisilicon: Fix potential use-after-free in hisifemacrx()

The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.

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

wifi: mac8021: fix possible oob access in ieee80211getrateduration

Fix possible out-of-bound access in ieee80211getrateduration routine as reported by the following UBSAN report:

UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47 index 15 is out of range for type 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017 Workqueue: mt76 mt76utxstatusdata [mt76usb] Call Trace: <TASK> showstack+0x4e/0x61 dumpstacklvl+0x4a/0x6f dumpstack+0x10/0x18 ubsanepilogue+0x9/0x43 ubsanhandleoutofbounds.cold+0x42/0x47 ieee80211getrateduration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211txstatusext+0x32e/0x640 [mac80211] ieee80211calcrxairtime+0xda/0x120 [mac80211] ieee80211calctxairtime+0xb4/0x100 [mac80211] mt76x02sendtxstatus+0x266/0x480 [mt76x02lib] mt76x02txstatusdata+0x52/0x80 [mt76x02lib] mt76utxstatusdata+0x67/0xd0 [mt76usb] processonework+0x225/0x400 workerthread+0x50/0x3e0 ? processonework+0x400/0x400 kthread+0xe9/0x110 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30

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

net: dsa: sja1105: avoid out of bounds access in sja1105initl2policing()

The SJA1105 family has 45 L2 policing table entries (SJA1105MAXL2POLICINGCOUNT) and SJA1110 has 110 (SJA1110MAXL2POLICINGCOUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT.

The sja1105initl2policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed.

The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->numports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->maxentrycount (SJA1105MAXL2POLICINGCOUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config.

The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated.

With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN.

Kernel log:

sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: eventsunbound deferredprobeworkfunc Call trace: ... sja1105setup+0x1cbc/0x2340 dsaregisterswitch+0x1284/0x18d0 sja1105probe+0x748/0x840 ... Allocated by task 8: ... sja1105setup+0x1bcc/0x2340 dsaregisterswitch+0x1284/0x18d0 sja1105probe+0x748/0x840 ...

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

fscache: Fix oops due to race with cookielru and usecookie

If a cookie expires from the LRU and the LRUDISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscacheusecookie and begin to use it.

When the cookieworker finally runs, it will see the LRUDISCARD flag set, transition the cookie->state to LRUDISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL.

Fix the oops by clearing the LRUDISCARD bit if another thread uses the cookie before the cookieworker runs.

BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x8664 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: eventsunbound netfsrreqwritetocachework [netfs] RIP: 0010:cachefilespreparewrite+0x28/0x90 [cachefiles] ... Call Trace: netfsrreqwritetocachework+0x11c/0x320 [netfs] processonework+0x217/0x3e0 workerthread+0x4a/0x3b0 kthread+0xd6/0x100

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

hwmon: (ibmpex) Fix possible UAF when ibmpexregisterbmc() fails

Smatch report warning as follows:

drivers/hwmon/ibmpex.c:509 ibmpexregisterbmc() warn: '&data->list' not removed from list

If ibmpexfindsensors() fails in ibmpexregisterbmc(), data will be freed, but data->list will not be removed from driverdata.bmcdata, then list traversal may cause UAF.

Fix by removeing it from driverdata.bmcdata before free().

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

e100: Fix possible use after free in e100xmitprepare

In e100xmitprepare(), if we can't map the skb, then return -ENOMEM, so e100xmitframe() will return NETDEVTXBUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb.

Remove the harmful free.

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

libbpf: Handle size overflow for ringbuf mmap

The maximum size of ringbuf is 2GB on x86-64 host, so 2 maxentries will overflow u32 when mapping producer page and data pages. Only casting maxentries to sizet is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow sizet.

So fixing it by casting the size of read-only mmap region into a u64 and checking whether or not there will be overflow during mmap.

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

tracing: Free buffers when a used dynamic event is removed

After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob.

The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used.

To show how this can be an issue, the following can crash the kernel:

# cd /sys/kernel/tracing # for i in seq 65536; do echo 'p:kprobes/foo dosysopenat2 $arg1:u32' > kprobeevents # done

For every iteration of the above, the writing to the kprobeevents will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same.

Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the dosysopenat2 function call's first parameter as an integer.

# echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (dosysopenat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (dosysopenat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (dosysopenat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (dosysopenat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable

Now if we delete the kprobe and create a new one that reads a string:

# echo 'p:kprobes/foo dosysopenat2 +0($arg2):string' > kprobeevents

And now we can the trace:

# cat trace sendmail-1942 [002] ..... 530.136320: foo: (dosysopenat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (dosysopenat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (dosysopenat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (dosysopenat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (dosysopenat2+0x0/0x240) arg1="��������������������������������������� ---truncated---

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

s390: avoid using global register for currentstackpointer

Commit 30de14b1884b ("s390: currentstackpointer shouldn't be a function") made currentstackpointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions.

Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for currentstackpointer.

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

scsi: zfcp: Fix double free of FSF request when qdio send fails

We used to use the wrong type of integer in 'zfcpfsfreqsend()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again).

In 'zfcpfsfreqsend()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcpreqlistfindrm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice).

If we can't successfully remove the request from the hash table again after 'zfcpqdiosend()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcpfsfreqsend()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice.

The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice:

listdel corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (listdelentryvalid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] listdelentryvalid+0x98/0x140 ([<00000003cbeea1f4>] listdelentryvalid+0x94/0x140) [<000003ff7ff502fe>] zfcpfsfreqdismissall+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcperpstrategydoaction+0x160/0x280 [zfcp] ---truncated---

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

kprobes: Skip clearing aggrprobe's posthandler in kprobe-on-ftrace case

In unregisterkprobetop(), if the currently unregistered probe has posthandler but other child probes of the aggrprobe do not have posthandler, the posthandler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarmkprobe(), we will use kprobeftraceops because posthandler is NULL. But we're armed with kprobeipmodifyops. This triggers a WARN in disarmkprobeftrace() and may even cause use-after-free:

Failed to disarm kprobe-ftrace at kernelclone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 disarmkprobeftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> disablekprobe+0xcd/0xe0 unregisterkprobetop+0x12/0x150 ? mutexlock+0xe/0x30 unregisterkprobes.part.23+0x31/0xa0 unregisterkprobe+0x32/0x40 x64sysdeletemodule+0x15e/0x260 ? douseraddrfault+0x2cd/0x6b0 dosyscall64+0x3a/0x90 entrySYSCALL64afterhwframe+0x63/0xcd [...]

For the kprobe-on-ftrace case, we keep the posthandler setting to identify this aggrprobe armed with kprobeipmodifyops. This way we can disarm it correctly.

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

drbd: use after free in drbdcreatedevice()

The drbddestroyconnection() frees the "connection" so use the safe() iterator to prevent a use after free.

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

ata: libata-transport: fix double atahostput() in atatportadd()

In the error path in atatportadd(), when calling putdevice(), atatportrelease() is called, it will put the refcount of 'ap->host'.

And then atahostput() is called again, the refcount is decreased to 0, atahostrelease() is called, all ports are freed and set to null.

When unbinding the device after failure, atahoststop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : atahoststop+0x3c/0x84 [libata] lr : releasenodes+0x64/0xd0 Call trace: atahoststop+0x3c/0x84 [libata] releasenodes+0x64/0xd0 devresreleaseall+0xbc/0x1b0 deviceunbindcleanup+0x20/0x70 reallyprobe+0x158/0x320 driverprobedevice+0x84/0x120 driverprobedevice+0x44/0x120 driverattach+0xb4/0x220 busforeachdev+0x78/0xdc driverattach+0x2c/0x40 busadddriver+0x184/0x240 driverregister+0x80/0x13c pciregisterdriver+0x4c/0x60 ahcipcidriverinit+0x30/0x1000 [ahci]

Fix this by removing redundant atahostput() in the error path.

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

nilfs2: fix use-after-free bug of nswriter on remount

If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time.

In these cases, use-after-free of the log writer (hereinafter nilfs->nswriter) can happen as shown in the scenario below:

Task1 Task2 -------------------------------- ------------------------------ nilfsconstructsegment nilfssegctorsync initwait initwaitqueueentry addwaitqueue schedule nilfsremount (R/W remount case) nilfsattachlogwriter nilfsdetachlogwriter nilfssegctordestroy kfree finishwait rawspinlockirqsave rawspinlockirqsave dorawspinlock debugspinlockbefore <-- use-after-free

While Task1 is sleeping, nilfs->nswriter is freed by Task2. After Task1 waked up, Task1 accesses nilfs->nswriter which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1].

This patch fixes the issue by not detaching nilfs->nswriter on remount so that this UAF race doesn't happen. Along with this change, this patch also inserts a few necessary read-only checks with superblock instance where only the nswriter pointer was used to check if the filesystem is read-only.

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

ASoC: core: Fix use-after-free in sndsocexit()

KASAN reports a use-after-free:

BUG: KASAN: use-after-free in devicedel+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl+0x79/0x9a printreport+0x17f/0x47b kasanreport+0xbb/0xf0 devicedel+0xb5b/0xc60 platformdevicedel.part.0+0x24/0x200 platformdeviceunregister+0x2e/0x40 sndsocexit+0xa/0x22 [sndsoccore] dosysdeletemodule.constprop.0+0x34f/0x5b0 dosyscall64+0x3a/0x90 entrySYSCALL64afterhwframe+0x63/0xcd ... </TASK>

It's bacause in sndsocinit(), sndsocutilinit() is possble to fail, but its ret is ignored, which makes socdummydev unregistered twice.

sndsocinit() sndsocutilinit() platformdeviceregistersimple(socdummydev) platformdriverregister() # fail platformdeviceunregister(socdummydev) platformdriverregister() # success ... sndsocexit() sndsocutilexit() # socdummydev will be unregistered for second time

To fix it, handle error and stop sndsocinit() when utilinit() fail. Also clean debugfs when utilinit() or driverregister() fail.

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

net: lapbether: fix issue of invalid opcode in lapbethopen()

If lapbregister() failed when lapb device goes to up for the first time, the NAPI is not disabled. As a result, the invalid opcode issue is reported when the lapb device goes to up for the second time.

The stack info is as follows: [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442! [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1958.315979][T11356] RIP: 0010:napienable+0x16a/0x1f0 [ 1958.332310][T11356] Call Trace: [ 1958.332817][T11356] <TASK> [ 1958.336135][T11356] lapbethopen+0x18/0x90 [ 1958.337446][T11356] devopen+0x258/0x490 [ 1958.341672][T11356] devchangeflags+0x4d4/0x6a0 [ 1958.345325][T11356] devchangeflags+0x93/0x160 [ 1958.346027][T11356] devinetioctl+0x1276/0x1bf0 [ 1958.346738][T11356] inetioctl+0x1c8/0x2d0 [ 1958.349638][T11356] sockioctl+0x5d1/0x750 [ 1958.356059][T11356] x64sysioctl+0x3ec/0x1790 [ 1958.365594][T11356] dosyscall64+0x35/0x80 [ 1958.366239][T11356] entrySYSCALL64afterhwframe+0x46/0xb0 [ 1958.377381][T11356] </TASK>

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

btrfs: fix tree mod log mishandling of reallocated nodes

We have been seeing the following panic in production

kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:treemodlogrewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfsgetoldroot+0x12b/0x420 btrfssearcholdslot+0x64/0x2f0 ? treemodlogoldestroot+0x3d/0xf0 resolveindirectref+0xfd/0x660 ? ulistalloc+0x31/0x60 ? kmemcachealloctrace+0x114/0x2c0 findparentnodes+0x97a/0x17e0 ? ulistalloc+0x30/0x60 btrfsfindallrootssafe+0x97/0x150 iterateextentinodes+0x154/0x370 ? btrfssearchpathintree+0x240/0x240 iterateinodesfromlogical+0x98/0xd0 ? btrfssearchpathintree+0x240/0x240 btrfsioctllogicaltoino+0xd9/0x180 btrfsioctl+0xe2/0x2ec0 ? modmemcglruvecstate+0x3d/0x280 ? dosysopenat2+0x6d/0x140 ? kretprobedispatcher+0x47/0x70 ? kretproberethookhandler+0x38/0x50 ? rethooktrampolinehandler+0x82/0x140 ? archrethooktrampolinecallback+0x3b/0x50 ? kmemcachefree+0xfb/0x270 ? dosysopenat2+0xd5/0x140 x64sysioctl+0x71/0xb0 dosyscall64+0x2d/0x40

Which is this code in treemodlogrewind()

switch (tm->op) { case BTRFSMODLOGKEYREMOVEWHILEFREEING: BUGON(tm->slot < n);

This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVEWHILEFREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVEWHILEFREEING operations.

The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events

1. We have an already modified root, and we do a btrfsgettreemodseq(). 2. We begin removing items from this root, triggering KEYREPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root.

The tree mod log looks something like this

logical 0 op KEYREPLACE (slot 1) seq 2 logical 0 op KEYREMOVE (slot 1) seq 3 logical 0 op KEYREMOVEWHILEFREEING (slot 0) seq 4 logical 4096 op LOGROOTREPLACE (old logical 0) seq 5 logical 8192 op KEYREMOVEWHILEFREEING (slot 1) seq 6 logical 8192 op KEYREMOVEWHILEFREEING (slot 0) seq 7 logical 0 op LOGROOTREPLACE (old logical 8192) seq 8

From here the bug is triggered by the following steps

1. Call btrfsgetoldroot() on the newroot. 2. We call treemodlogoldestroot(btrfsrootnode(newroot)), which is currently logical 0. 3. treemodlogoldestroot() calls treemodlogsearcholdest(), which gives us the KEYREPLACE seq 2, and since that's not a LOGROOTREPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOGROOTREPLACE. 4. Back in treemodlogoldestroot() we don't have a LOGROOTREPLACE, so we don't set oldroot, we simply use our e ---truncated---

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

i2c: piix4: Fix adapter not be removed in piix4remove()

In piix4probe(), the piix4 adapter will be registered in:

piix4probe() piix4addadapterssb800() / piix4addadapter() i2caddadapter()

Based on the probed device type, piix4addadapterssb800() or single piix4addadapter() will be called. For the former case, piix4adaptercount is set as the number of adapters, while for antoher case it is not set and kept default zero.

When piix4 is removed, piix4remove() removes the adapters added in piix4probe(), basing on the piix4adaptercount value. Because the count is zero for the single adapter case, the adapter won't be removed and makes the sources allocated for adapter leaked, such as the i2c client and device.

These sources can still be accessed by i2c or bus and cause problems. An easily reproduced case is that if a new adapter is registered, i2c will get the leaked adapter and try to call smbusalgorithm, which was already freed:

Triggered by: rmmod i2cpiix4 && modprobe max31730

BUG: unable to handle page fault for address: ffffffffc053d860 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3752 Comm: modprobe Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2cdefaultprobe (drivers/i2c/i2c-core-base.c:2259) i2ccore RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... <TASK> i2cdetect (drivers/i2c/i2c-core-base.c:2302) i2ccore processnewdriver (drivers/i2c/i2c-core-base.c:1336) i2ccore busforeachdev (drivers/base/bus.c:301) i2cforeachdev (drivers/i2c/i2c-core-base.c:1823) i2ccore i2cregisterdriver (drivers/i2c/i2c-core-base.c:1861) i2ccore dooneinitcall (init/main.c:1296) doinitmodule (kernel/module/main.c:2455) ... </TASK> ---[ end trace 0000000000000000 ]---

Fix this problem by correctly set piix4adaptercount as 1 for the single adapter so it can be normally removed.

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

KVM: Initialize gfntopfncache locks in dedicated helper

Move the gfntopfncache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvmgfntopfncacheinit()'s ability to re-initialize the cache's locks.

For example: a race between ioctl(KVMXENHVMEVTCHNSEND) and kvmgfntopfncacheinit() leads to a corrupted shinfo gpc lock.

(thread 1) | (thread 2) | kvmxensetevtchnfast | readlockirqsave(&gpc->lock, ...) | | kvmgfntopfncacheinit | rwlockinit(&gpc->lock) readunlockirqrestore(&gpc->lock, ...) |

Rename "cacheinit" and "cachedestroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed.

Note, there more races in the newly named kvmgpcactivate() that will be addressed separately.

[sean: call out that this is a bug fix]