In the Linux kernel, the following vulnerability has been resolved:
net: vertexcom: mse102x: Fix possible double free of TX skb
The scope of the TX skb is wider than just mse102xtxframespi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102xtxwork(), which leads to crashes:
Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102xtxwork [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbreleasedata+0xb8/0x1d8 lr : skbreleasedata+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skbreleasedata+0xb8/0x1d8 kfreeskbreason+0x48/0xb0 mse102xtxwork+0x164/0x35c [mse102x] processonework+0x138/0x260 workerthread+0x32c/0x438 kthread+0x118/0x11c retfromfork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)
In the Linux kernel, the following vulnerability has been resolved:
skbuff: fix coalescing for pagepool fragment recycling
Fix a use-after-free when using pagepool with page fragments. We encountered this problem during normal RX in the hns3 driver:
(1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through pagepool, and the other two allocate one half of PAGE2 each. Page references look like this:
RXBD1 PAGE1 RXBD2 PAGE2 RXBD3 /
(2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcpqueuercv().
(3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netifreceiveskb():
netifreceiveskb(SKB2) iprcv(SKB2) SKB3 = skbclone(SKB2)
SKB2 and SKB3 share a reference to PAGE2 through skbshinfo()->dataref. The other ref to PAGE2 is still held by RXBD3:
SKB2 ---+- PAGE2 SKB3 / / RXBD3 /
(3b) Now while handling TCP, coalesce SKB3 with SKB1:
tcpv4rcv(SKB3) tcptrycoalesce(to=SKB1, from=SKB3) // succeeds kfreeskbpartial(SKB3) skbreleasedata(SKB3) // drops one dataref
SKB1 PAGE1 \ SKB2 PAGE2 / RXBD3 /
In skbtrycoalesce(), skbfragref() takes a page reference to PAGE2, where it should instead have increased the pagepool frag reference, ppfragcount. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow.
(3c) Drop SKB2:
afpacketrcv(SKB2) consumeskb(SKB2) skbreleasedata(SKB2) // drops second dataref pagepoolreturnskbpage(PAGE2) // drops one ppfragcount
SKB1 PAGE1 \ PAGE2 / RXBD3 /
(4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well:
tcpeatrecvskb(SKB1) skbreleasedata(SKB1) pagepoolreturnskbpage(PAGE1) pagepoolreturnskbpage(PAGE2) // drops second ppfragcount
(5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled.
Change the logic that checks whether pprecycle SKBs can be coalesced. We still reject differing pprecycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pprecycled and 'from' is cloned.
The new logic allows coalescing a cloned pprecycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skbtrycoalesce().
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix call timer start racing with call destruction
The rxrpccall struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first.
Fix this by trying to take a ref on the rxrpccall struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded.
The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded.
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix slab-out-of-bounds bug in decryptinternal
The memory size of tlsctx->rx.iv for AES128-CCM is 12 setting in tlssetswoffload(). The return value of cryptoaeadivsize() for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes memory space will trigger slab-out-of-bounds bug as following:
================================================================== BUG: KASAN: slab-out-of-bounds in decryptinternal+0x385/0xc40 [tls] Read of size 16 at addr ffff888114e84e60 by task tls/10911
Call Trace: <TASK> dumpstacklvl+0x34/0x44 printreport.cold+0x5e/0x5db ? decryptinternal+0x385/0xc40 [tls] kasanreport+0xab/0x120 ? decryptinternal+0x385/0xc40 [tls] kasancheckrange+0xf9/0x1e0 memcpy+0x20/0x60 decryptinternal+0x385/0xc40 [tls] ? tlsgetrec+0x2e0/0x2e0 [tls] ? processrxlist+0x1a5/0x420 [tls] ? tlssetupfromiter.constprop.0+0x2e0/0x2e0 [tls] decryptskbupdate+0x9d/0x400 [tls] tlsswrecvmsg+0x3c8/0xb50 [tls]
Allocated by task 10911: kasansavestack+0x1e/0x40 kasankmalloc+0x81/0xa0 tlssetswoffload+0x2eb/0xa20 [tls] tlssetsockopt+0x68c/0x700 [tls] syssetsockopt+0xfe/0x1b0
Replace the cryptoaeadivsize() with prot->ivsize + prot->saltsize when memcpy() iv value in TLS13VERSION scenario.
In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: Use stronger register read/writes to assure ordering
GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like:
[ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/schgeneric.c:529 devwatchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppcscalefreqworkfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : devwatchdog+0x234/0x240 [ 210.161364] lr : devwatchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] devwatchdog+0x234/0x240 [ 210.275811] calltimerfn+0x3c/0x15c [ 210.279489] runtimers.part.0+0x288/0x310 [ 210.283777] runtimersoftirq+0x48/0x80 [ 210.287716] dosoftirq+0x128/0x360 [ 210.291392] irqexitrcu+0x138/0x140 [ 210.295243] irqexitrcu+0x1c/0x30 [ 210.298745] el1interrupt+0x38/0x54 [ 210.302334] el1h64irqhandler+0x18/0x24 [ 210.306445] el1h64irq+0x7c/0x80 [ 210.309857] archcpuidle+0x18/0x2c [ 210.313445] defaultidlecall+0x4c/0x140 [ 210.317470] cpuidleidlecall+0x14c/0x1a0 [ 210.321584] doidle+0xb0/0x100 [ 210.324737] cpustartupentry+0x30/0x8c [ 210.328675] secondarystartkernel+0xe4/0x110 [ 210.333138] secondaryswitched+0x94/0x98
The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations.
Its possible to suppress the timeout with a liberal bit of dmamb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere.
Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to ibmvnicxmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnicxmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] devhardstartxmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnicxmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] devhardstartxmit+0x11c/0x280 [c000000000c9cfcc] schdirectxmit+0xec/0x330 [c000000000bfe640] devxmitskb+0x3a0/0x9d0 [c000000000c00ad4] devqueuexmit+0x394/0x730 [c008000002db813c] bondstartxmit+0x254/0x450 [bonding] [c008000002db8378] bondstartxmit+0x40/0xc0 [bonding] [c000000000c0046c] devhardstartxmit+0x11c/0x280 [c000000000c00ca4] devqueuexmit+0x564/0x730 [c000000000cf97e0] neighhhoutput+0xd0/0x180 [c000000000cfa69c] ipfinishoutput2+0x31c/0x5c0 [c000000000cfd244] ipqueuexmit+0x194/0x4f0 [c000000000d2a3c4] tcptransmitskb+0x434/0x9b0 [c000000000d2d1e0] tcpretransmitskb+0x1d0/0x6a0 [c000000000d2d984] tcpretransmitskb+0x34/0x130 [c000000000d310e8] tcpretransmittimer+0x388/0x6d0 [c000000000d315ec] tcpwritetimerhandler+0x1bc/0x330 [c000000000d317bc] tcpwritetimer+0x5c/0x200 [c000000000243270] calltimerfn+0x50/0x1c0 [c000000000243704] runtimers.part.0+0x324/0x460 [c000000000243894] runtimersoftirq+0x54/0xa0 [c000000000ea713c] dosoftirq+0x15c/0x3e0 [c000000000166258] irqexitrcu+0x158/0x190 [c000000000166420] irqexit+0x20/0x40 [c00000000002853c] timerinterrupt+0x14c/0x2b0 [c000000000009a00] decrementercommonvirt+0x210/0x220 --- interrupt: 900 at plparhcallnoretsnotrace+0x18/0x2c
The immediate cause of the crash is the access of txscrq in the following snippet during a reset, where the txscrq can be either NULL or an address that will soon be invalid:
ibmvnicxmit() { ... txscrq = adapter->txscrq[queuenum]; txq = netdevgettxqueue(netdev, queuenum); indbufp = &txscrq->indbuf;
if (testbit(0, &adapter->resetting)) { ... }
But beyond that, the call to ibmvnicxmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvniccleanup(). However just after the queue was stopped, an in-flight ibmvniccompletetx() could have restarted the queue even as the reset is progressing.
Since the queue was restarted we could get a call to ibmvnicxmit() which can then access the bad txscrq (or other fields).
We cannot however simply have ibmvniccompletetx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvniccompletetx() and others wake up the queue only if the queue is marked active.
So we will have: A. reset/open thread in ibmvniccleanup() and ibmvnicopen()
->resetting = true ->txqueuesactive = false disable tx queues ... ->txqueuesactive = true start tx queues
B. Tx interrupt in ibmvniccompletetx():
if (->txqueuesactive) netifwakesubqueue();
To ensure that ->txqueuesactive and state of the queues are consistent, we need a lock which:
- must also be taken in the interrupt path (ibmvniccompletetx()) - shared across the multiple ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - fix the aead software fallback for engine
Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent underflow in nfssvcdecodewriteargs()
Smatch complains:
fs/nfsd/nfsxdr.c:341 nfssvcdecodewriteargs() warn: no lower bound on 'args->len'
Change the type to unsigned to prevent this issue.
In the Linux kernel, the following vulnerability has been resolved:
net: ioam6: fix OOB and missing lock
When trace->type.bit6 is set:
if (trace->type.bit6) { ... queue = skbgettxqueue(dev, skb); qdisc = rcudereference(queue->qdisc);
This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettxqueue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.
While at it, add missing lock around qdiscqstatsqlenbacklog(). The function ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.
A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.
Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.
When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hcisendacl
This fixes the following trace caused by receiving HCIEVDISCONNPHYLINKCOMPLETE which does call hciconndel without first checking if conn->type is in fact AMPLINK and in case it is do properly cleanup upper layers with hcidisconncfm:
================================================================== BUG: KASAN: use-after-free in hcisendacl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x45/0x59 printaddressdescription.constprop.0+0x1f/0x150 kasanreport.cold+0x7f/0x11b hcisendacl+0xaba/0xc50 l2capdosend+0x23f/0x3d0 l2capchansend+0xc06/0x2cc0 l2capsocksendmsg+0x201/0x2b0 socksendmsg+0xdc/0x110 sockwriteiter+0x20f/0x370 doiterreadvwritev+0x343/0x690 doiterwrite+0x132/0x640 vfswritev+0x198/0x570 dowritev+0x202/0x280 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIGRAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 </TASK> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0
Allocated by task 45: kasansavestack+0x1e/0x40 kasankmalloc+0x81/0xa0 hcichancreate+0x9a/0x2f0 l2capconnadd.part.0+0x1a/0xdc0 l2capconnectcfm+0x236/0x1000 leconncompleteevt+0x15a7/0x1db0 hcileconncompleteevt+0x226/0x2c0 hcilemetaevt+0x247/0x450 hcieventpacket+0x61b/0xe90 hcirxwork+0x4d5/0xc50 processonework+0x8fb/0x15a0 workerthread+0x576/0x1240 kthread+0x29d/0x340 retfromfork+0x1f/0x30
Freed by task 45: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansetfreeinfo+0x20/0x30 kasanslabfree+0xfb/0x130 kfree+0xac/0x350 hciconncleanup+0x101/0x6a0 hciconndel+0x27e/0x6c0 hcidisconnphylinkcompleteevt+0xe0/0x120 hcieventpacket+0x812/0xe90 hcirxwork+0x4d5/0xc50 processonework+0x8fb/0x15a0 workerthread+0x576/0x1240 kthread+0x29d/0x340 retfromfork+0x1f/0x30
The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix use after free in fcexchabtsresp()
fcexchrelease(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free.
Return after the fcexchrelease() call to avoid use after free.
In the Linux kernel, the following vulnerability has been resolved:
ath11k: free peer for station when disconnect from AP for QCA6390/WCN6855
Commit b4a0f54156ac ("ath11k: move peer delete after vdev stop of station for QCA6390 and WCN6855") is to fix firmware crash by changing the WMI command sequence, but actually skip all the peer delete operation, then it lead commit 58595c9874c6 ("ath11k: Fixing dangling pointer issue upon peer delete failure") not take effect, and then happened a use-after-free warning from KASAN. because the peer->sta is not set to NULL and then used later.
Change to only skip the WMIPEERDELETECMDID for QCA6390/WCN6855.
log of user-after-free:
[ 534.888665] BUG: KASAN: use-after-free in ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860
[ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted: G W 5.15.0-wt-ath+ #523 [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 534.888716] Call Trace: [ 534.888720] <IRQ> [ 534.888726] dumpstacklvl+0x57/0x7d [ 534.888736] printaddressdescription.constprop.0+0x1f/0x170 [ 534.888745] ? ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888771] kasanreport.cold+0x83/0xdf [ 534.888783] ? ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888810] ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888840] ath11kdprxprocessmonstatus+0x529/0xa70 [ath11k] [ 534.888874] ? ath11kdprxmonstatusbufsreplenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? checkprevadd+0x20f0/0x20f0 [ 534.888922] ? lockacquire+0xb72/0x1870 [ 534.888937] ? findheldlock+0x33/0x110 [ 534.888954] ath11kdprxprocessmonrings+0x297/0x520 [ath11k] [ 534.888981] ? rcureadunlock+0x40/0x40 [ 534.888990] ? ath11kdprxpdevalloc+0xd90/0xd90 [ath11k] [ 534.889026] ath11kdpservicemonring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11kdprxprocessmonrings+0x520/0x520 [ath11k] [ 534.889075] calltimerfn+0x167/0x4a0 [ 534.889084] ? addtimeron+0x3b0/0x3b0 [ 534.889103] ? lockdephardirqsonprepare.part.0+0x18c/0x370 [ 534.889117] runtimers.part.0+0x539/0x8b0 [ 534.889123] ? ath11kdprxprocessmonrings+0x520/0x520 [ath11k] [ 534.889157] ? calltimerfn+0x4a0/0x4a0 [ 534.889164] ? marklockirq+0x1c30/0x1c30 [ 534.889173] ? clockeventsprogramevent+0xdd/0x280 [ 534.889189] ? markheldlocks+0xa5/0xe0 [ 534.889203] runtimersoftirq+0x97/0x180 [ 534.889213] dosoftirq+0x276/0x86a [ 534.889230] irqexitrcu+0x11c/0x180 [ 534.889238] irqexitrcu+0x5/0x20 [ 534.889244] sysvecapictimerinterrupt+0x8e/0xc0 [ 534.889251] </IRQ> [ 534.889254] <TASK> [ 534.889259] asmsysvecapictimerinterrupt+0x12/0x20 [ 534.889265] RIP: 0010:rawspinunlockirqrestore+0x38/0x70 [ 534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 0000000000000006 RBX: 0000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI: 0000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f [ 534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? marklock+0xd0/0x14a0 [ 534.889332] klistnext+0x1d4/0x450 [ 534.889340] ? dpmwaitforsubordinate+0x2d0/0x2d0 [ 534.889350] deviceforeachchild+0xa8/0x140 [ 534.889360] ? deviceremoveclasssymlinks+0x1b0/0x1b0 [ 534.889370] ? lockrelease+0x4bd/0x9f0 [ 534.889378] ? dpmsuspend+0x26b/0x3f0 [ 534.889390] dpmwaitforsubordinate+ ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcievent: fix potential UAF in hcileremoteconnparamreqevt
hciconn lookup and field access must be covered by hdev lock in hcileremoteconnparamreqevt, otherwise it's possible it is freed concurrently.
Extend the hcidevlock critical section to cover all conn usage.
A use-after-free exists in the Linux Kernel in tcnewtfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: re-fix fortified-memset warning
The carl9170txrelease() function sometimes triggers a fortified-memset warning in my randconfig builds:
In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortifymemsetchk', inlined from 'carl9170txrelease' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'krefput' at include/linux/kref.h:65:3, inlined from 'carl9170txputskb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to 'writeoverflowfield' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use structgroup()? [-Werror=attribute-warning] 493 | writeoverflowfield(psizefield, size);
Kees previously tried to avoid this by using memsetafter(), but it seems this does not fully address the problem. I noticed that the memsetafter() here is done on a different part of the union (status) than the original cast was from (ratedriverdata), which may confuse the compiler.
Unfortunately, the memsetafter() trick does not work on driverrates[] because that is part of an anonymous struct, and I could not get structgroup() to do this either. Using two separate memset() calls on the two members does address the warning though.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent integer overflow on 32 bit systems
On a 32 bit system, the "len sizeof(p)" operation can have an integer overflow.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve overflow the qgroup limit
We use extentchangeset->byteschanged in qgroupreservedata() to record how many bytes we set for EXTENTQGROUPRESERVED state. Currently the byteschanged is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit.
Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem.
The following example test script reproduces the problem:
$ cat qgroup-overflow.sh #!/bin/bash
DEV=/dev/sdj MNT=/mnt/sdj
mkfs.btrfs -f $DEV mount $DEV $MNT
# Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT
# Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file
# Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file
# See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT
umount $MNT
When running the test:
$ ./qgroup-overflow.sh (...)
Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded
Try to fallocate a 5GiB file...
qgroupid rfer excl maxrfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB
Since we have no control of how byteschanged is used, it's better to set it to u64.
A flaw in the Linux Kernel found. If unprivileged users can mount FUSE filesystems, then can trigger use after free (UAF) that reads of write() buffers, allowing theft of (partial) /etc/shadow hashes or any other data from filesystem.
FUSE allows the userspace filesystem to specify on FUSEOPEN whether the file should use the normal kernel pagecache for handling read()/write() or just send FUSEREAD/FUSEWRITE requests directly to the userspace filesystem (using the flag FOPENDIRECTIO in fuseopenout::openflags).
In FOPENDIRECTIO mode, fusefilewriteiter() calls fusedirectwriteiter(), which normally calls fusedirectio(), which then imports the write buffer with fusegetuserpages(), which uses iovitergetpages() to grab references to userspace pages instead of actually copying memory.
On the filesystem device side, these pages can then either be read to userspace (via fusedevread()), or splice()d over into a pipe using fusedevspliceread() as pipe buffers with &nostealpipebufops.
This is wrong because after fusedevdoread() unlocks the FUSE request, the userspace filesystem can mark the request as completed, causing write() to return. At that point, the write buffer may be reused for other purposes, and the userspace filesystem should no longer have access to it.
A flaw use after free in the Linux kernel video4linux driver was found in the way user triggers em28xxusbprobe() for the Empia 28xx based TV cards. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
In the Linux kernel, the following vulnerability has been resolved:
pwm: Fix out-of-bounds access in ofpwmsinglexlate()
With args->argscount == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1].
A use-after-free flaw was found in net/sunrpc/xprt.c in the Remote Procedure Call (SunRPC) protocol in the Linux kernel. This flaw could allow a local attacker to crash, and this may even lead to a kernel information leak problem.
References:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a http://www.openwall.com/lists/oss-security/2022/04/11/4 http://www.openwall.com/lists/oss-security/2022/04/11/3
A flaw was found in KVM. When updating a guest's page table entry, vmpgoff was improperly used as the offset to get the page's pfn. As vaddr and vmpgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition.
In the Linux kernel, the following vulnerability has been resolved:
block: Fix iterating over an empty bio with bioforeachfolioall
If the bio contains no data, biofirstfolio() calls pagefolio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bionextfolio() to biofirstfolio().
[axboe: add unlikely() to error case]
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: think-lmi: Fix password opcode ordering for workstations
The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled).
Tested on some Thinkpads to confirm they are OK with this order too.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in sndemu10k1pcmchannelalloc()
The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however sndemu10k1pcmchannelalloc() accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough index so that firstvoice + requestedvoicecount > NUMG (64). The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'sndemu10k1voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dumpstacklvl+0x49/0x63 dumpstack+0x10/0x16 ubsanepilogue+0x9/0x3f ubsanhandleoutofbounds.cold+0x44/0x49 sndemu10k1playbackhwparams+0x3bc/0x420 [sndemu10k1] sndpcmhwparams+0x29f/0x600 [sndpcm] sndpcmcommonioctl+0x188/0x1410 [sndpcm] ? exittousermodeprepare+0x35/0x170 ? dosyscall64+0x69/0x90 ? syscallexittousermode+0x26/0x50 ? dosyscall64+0x69/0x90 ? exittousermodeprepare+0x35/0x170 sndpcmioctl+0x27/0x40 [sndpcm] x64sysioctl+0x95/0xd0 dosyscall64+0x5c/0x90 ? dosyscall64+0x69/0x90 ? dosyscall64+0x69/0x90 entrySYSCALL64afterhwframe+0x63/0xcd
ax25: Fix netdev refcount issue
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.