In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Trap RDMA segment overflows
Prevent svcrdmabuildwrites() from walking off the end of a Write chunk's segment array. Caught with KASAN.
The test that this fix replaces is invalid, and might have been left over from an earlier prototype of the PCL work.
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix plock invalid read
This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plockop" and a followed sendop() will append it to a global sendlist data structure. In some cases a followed devread() moves it to recvlist and devwrite() will cast it to "struct plockxop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields.
To fix this issue the "callback" field is moved to "struct plockop" to indicate that a cast to "plockxop" is allowed and does the additional "plockxop" handling if set.
Example of the KASAN output which showed the invalid read:
[ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in devwrite+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlmcontrold/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlmcontrold Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dumpstacklvl+0x56/0x7b [ 2064.313150] printaddressdescription.constprop.8+0x21/0x150 [ 2064.314578] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.315610] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.316595] kasanreport.cold.14+0x7f/0x11b [ 2064.317674] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.318687] devwrite+0x52b/0x5a0 [dlm] [ 2064.319629] ? devread+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpflsmkernfsinitsecurity+0x10/0x10 [ 2064.321926] vfswrite+0x17e/0x930 [ 2064.322769] ? fgetlight+0x1aa/0x220 [ 2064.323753] ksyswrite+0xf1/0x1c0 [ 2064.324548] ? ia32sysread+0xb0/0xb0 [ 2064.325464] dosyscall64+0x3a/0x80 [ 2064.326387] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIGRAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasansavestack+0x1c/0x40 [ 2064.345079] kasankmalloc+0x84/0xa0 [ 2064.345933] kmemcachealloctrace+0x13b/0x220 [ 2064.346953] dlmposixunlock+0xec/0x720 [dlm] [ 2064.348811] dolockfilewait.part.32+0xca/0x1d0 [ 2064.351070] fcntlsetlk+0x281/0xbc0 [ 2064.352879] dofcntl+0x5e4/0xfe0 [ 2064.354657] x64sysfcntl+0x11f/0x170 [ 2064.356550] dosyscall64+0x3a/0x80 [ 2064.358259] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasansavestack+0x1c/0x40 [ 2064.365811] kasanrecordauxstack+0xaf/0xc0 [ 2064.368100] callrcu+0x11b/0xf70 [ 2064.369785] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.372404] receivefromsock+0x290/0x770 [dlm] [ 2064.374607] processrecvsockets+0x32/0x40 [dlm] [ 2064.377290] processonework+0x9a8/0x16e0 [ 2064.379357] workerthread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] retfromfork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasansavestack+0x1c/0x40 [ 2064.391043] kasanrecordauxstack+0xaf/0xc0 [ 2064.393303] callrcu+0x11b/0xf70 [ 2064.394885] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.397694] receivefromsock+0x290/0x770 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix potential use-after-free in nfsdfileput()
nfsdfileputnoref() can free @nf, so don't dereference @nf immediately upon return from nfsdfileputnoref().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: re-fetch conntrack after insertion
In case the conntrack is clashing, insertion can free skb->nfct and set skb->nfct to the already-confirmed entry.
This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()
Syzkaller reported a panic in smctcpsynrecvsock() [1].
smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().
This leads to two issues:
1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriafops) are accessed.
The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheckreq() path has the same race):
CPU A (softirq) CPU B (process ctx)
tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) / No lock on listener / smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!
Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.
Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.
- Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcureadlock(). - Use rcureadlock() to protect reading skuserdata. - Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smcsock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.
Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smcsock field, so it is not affected.
Reproducer was verified with mdelay injection and smcrun, the issue no longer occurs with this patch applied.
[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential for tearing in ->remoteisize and ->zeropoint
Fix potential tearing in using ->remoteisize and ->zeropoint by copying isizeread() and isizewrite() and using the same seqcount as for isize.
We need to make sure that netfslib and the filesystems that use it always hold ilock whilst updating any of the sizes to prevent isizeseqcount from getting corrupted.
btrfs: fix a race between renames and directory logging
In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix refcount imbalance on inbound connections
When releasing a socket in ax25release(), we call netdevput() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdevhold(). This imbalance leads to refcount errors, and ultimately to kernel crashes.
A typical call trace for the above situation will start with one of the following errors:
refcountt: decrement hit 0; leaking memory. refcountt: underflow; use-after-free.
And will then have a trace like:
Call Trace: <TASK> ? showregs+0x64/0x70 ? warn+0x83/0x120 ? refcountwarnsaturate+0xb2/0x100 ? reportbug+0x158/0x190 ? prbreadvalid+0x20/0x30 ? handlebug+0x3e/0x70 ? excinvalidop+0x1c/0x70 ? asmexcinvalidop+0x1f/0x30 ? refcountwarnsaturate+0xb2/0x100 ? refcountwarnsaturate+0xb2/0x100 ax25release+0x2ad/0x360 sockrelease+0x35/0xa0 sockclose+0x19/0x20 [...]
On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop:
unregisternetdevice: waiting for ax0 to become free. Usage count = 0
This patch corrects these issues by ensuring that we call netdevhold() and ax25devhold() for new connections in ax25accept(). This makes the logic leading to ax25accept() match the logic for ax25bind(): in both cases we increment the refcount, which is ultimately decremented in ax25release().
In the Linux kernel, the following vulnerability has been resolved:
mt76: fix use-after-free by removing a non-RCU wcid pointer
Fixes an issue caught by KASAN about use-after-free in mt76txqschedule by protecting mtxq->wcid with rculock between mt76txqschedule and stainfo[alloc, free].
[18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76txqschedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215
[18853.876840] Call trace: [18853.876861] dumpbacktrace+0x0/0x3ec [18853.876878] showstack+0x20/0x2c [18853.876899] dumpstack+0x11c/0x1ac [18853.876918] printaddressdescription+0x74/0x514 [18853.876934] kasanreport+0x134/0x174 [18853.876948] asanreportload8noabort+0x44/0x50 [18853.876976] mt76txqschedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76txqscheduleall+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921txworker+0xa0/0x1cc [mt7921common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] mt76workerfn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] retfromfork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasansavestack+0x38/0x68 [18853.877147] kasankmalloc+0xd4/0xfc [18853.877163] kasankmalloc+0x10/0x1c [18853.877177] kmalloc+0x264/0x3c4 [18853.877294] stainfoalloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211prepconnection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211mgdauth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211auth+0x20/0x2c [mac80211] [18853.877733] rdevauth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211mlmeauth+0x26c/0x390 [cfg80211] [18853.877919] nl80211authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genlrcvmsg+0x748/0x93c [18853.877954] netlinkrcvskb+0x160/0x2a8 [18853.877969] genlrcv+0x3c/0x54 [18853.877985] netlinkunicastkernel+0x104/0x1ec [18853.877999] netlinkunicast+0x178/0x268 [18853.878015] netlinksendmsg+0x3cc/0x5f0 [18853.878030] socksendmsg+0xb4/0xd8 [18853.878043] syssendmsg+0x2f8/0x53c [18853.878058] syssendmsg+0xe8/0x150 [18853.878071] syssendmsg+0xc4/0x1f4 [18853.878087] arm64compatsyssendmsg+0x88/0x9c [18853.878101] el0svccommon+0x1b4/0x390 [18853.878115] doel0svccompat+0x8c/0xdc [18853.878131] el0svccompat+0x10/0x1c [18853.878146] el0synccompathandler+0xa8/0xcc [18853.878161] el0synccompat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasansavestack+0x38/0x68 [18853.878215] kasansettrack+0x28/0x3c [18853.878228] kasansetfreeinfo+0x24/0x48 [18853.878244] kasanslabfree+0x11c/0x154 [18853.878259] kasanslabfree+0x14/0x24 [18853.878273] slabfreefreelisthook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] stainfofree+0x198/0x210 [mac80211] [18853.878515] stainfodestroypart2+0x230/0x2d4 [mac80211] [18853.878628] stainfoflush+0x300/0x37c [mac80211] [18853.878740] ieee80211setdisassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211mgddeauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211deauth+0x20/0x2c [mac80211] [18853.879057] rdevdeauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211mlmedeauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211mlmedown+0xe4/0x118 [cfg80211] [18853.879335] cfg80211disconnect+0x218/0x2d8 [cfg80211] [18853.879427] cfg80211leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211leave+0x3c/0x58 [cfg80211] [18853.879611] wiphysuspend+0xdc/0x200 [cfg80211] [18853.879628] dpmruncallback+0x58/0x408 [18853.879642] devicesuspend+0x4cc/0x864 [18853.879658] asyncsuspend+0x34/0xf4 [18 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix use-after-free in chanctx code
In ieee80211vifusereservedcontext(), when we have an old context and the new context's replacestate is set to IEEE80211CHANCTXREPLACENONE, we free the old context in ieee80211vifusereservedreassign(). Therefore, we cannot check the oldctx anymore, so we should set it to NULL after this point.
However, since the newctx replace state is clearly not IEEE80211CHANCTXREPLACESOTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed oldctx.
In the Linux kernel, the following vulnerability has been resolved:
rtw89: cfo: check macid to avoid out-of-bounds
Somehow, hardware reports incorrect macid and pollute memory. Check index before we access the array.
UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89pc Tainted: G OE Call Trace: <IRQ> showstack+0x52/0x58 dumpstacklvl+0x4c/0x63 dumpstack+0x10/0x12 ubsanepilogue+0x9/0x45 ubsanhandleoutofbounds.cold+0x44/0x49 ? allocskb+0x92/0x1d0 rtw89phycfoparse+0x44/0x7f [rtw89core] rtw89corerx+0x261/0x871 [rtw89core] ? allocskb+0xee/0x1d0 rtw89pcinapipoll+0x3fa/0x4ea [rtw89pci] napipoll+0x33/0x1a0 netrxaction+0x126/0x260 ? queuework+0x217/0x4c0 dosoftirq+0xd9/0x315 ? disableirqnosync+0x10/0x10 dosoftirq.part.0+0x6d/0x90 </IRQ> <TASK> localbhenableip+0x62/0x70 rtw89pciinterruptthreadfn+0x182/0x1a6 [rtw89pci] irqthreadfn+0x28/0x60 irqthread+0xc8/0x190 ? irqthreadfn+0x60/0x60 kthread+0x16b/0x190 ? irqthreadcheckaffinity+0xe0/0xe0 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix use-after-free at btmtksdiorecvevent
We should not access skb buffer data anymore after hcirecvframe was called.
[ 39.634809] BUG: KASAN: use-after-free in btmtksdiorecvevent+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dumpbacktrace+0x0/0x3b8 [ 39.634999] showstack+0x20/0x2c [ 39.635016] dumpstacklvl+0x60/0x78 [ 39.635040] printaddressdescription+0x70/0x2f0 [ 39.635062] kasanreport+0x154/0x194 [ 39.635079] asanreportload1noabort+0x44/0x50 [ 39.635099] btmtksdiorecvevent+0x1b0/0x1c4 [ 39.635129] btmtksdiotxrxwork+0x6cc/0xac4 [ 39.635157] processonework+0x560/0xc5c [ 39.635177] workerthread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] retfromfork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasansavestack+0x38/0x68 [ 39.635319] kasansettrack+0x28/0x3c [ 39.635338] kasansetfreeinfo+0x28/0x4c [ 39.635357] kasanslabfree+0x104/0x150 [ 39.635374] kasanslabfree+0x18/0x28 [ 39.635391] slabfreefreelisthook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skbfreehead+0x58/0x98 [ 39.635447] skbreleasedata+0x2f4/0x410 [ 39.635464] skbreleaseall+0x50/0x60 [ 39.635481] kfreeskb+0xc8/0x25c [ 39.635498] hcieventpacket+0x894/0xca4 [bluetooth] [ 39.635721] hcirxwork+0x1c8/0x68c [bluetooth] [ 39.635925] processonework+0x560/0xc5c [ 39.635951] workerthread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] retfromfork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)
In the Linux kernel, the following vulnerability has been resolved:
mt76: fix tx status related use-after-free race on station removal
There is a small race window where ongoing tx activity can lead to a skb getting added to the status tracking idr after that idr has already been cleaned up, which will keep the wcid linked in the status poll list. Fix this by only adding status skbs if the wcid pointer is still assigned in dev->wcid, which gets cleared early by mt76staprercuremove
In the Linux kernel, the following vulnerability has been resolved:
wl1251: dynamically allocate memory used for DMA
With introduction of vmap'ed stacks, stack parameters can no longer be used for DMA and now leads to kernel panic.
It happens at several places for the wl1251 (e.g. when accessed through SDIO) making it unuseable on e.g. the OpenPandora.
We solve this by allocating temporary buffers or use wl1251read32().
Tested on v5.18-rc5 with OpenPandora.
In the Linux kernel, the following vulnerability has been resolved:
ath10k: skip ath10khalt during suspend for driver state RESTARTING
Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10kcorerestart() which calls driver clean up via ath10khalt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10kstop() which again triggers ath10khalt() The double invocation of ath10khalt() causes ath10khttrxfree() to be called twice(Note: ath10khttrxalloc was not called by restart worker thread because of its frozen state), causing the crash.
To fix this, during the suspend flow, skip call to ath10khalt() in ath10kstop() when the current driver state is ATH10KSTATERESTARTING. Also, for driver state ATH10KSTATERESTARTING, call ath10kwaitforsuspend() in ath10kstop(). This is because call to ath10kwaitforsuspend() is skipped later in [ath10khalt() > ath10kcorestop()] for the driver state ATH10KSTATERESTARTING.
The frozen restart worker thread will be cancelled during resume when the device comes out of suspend.
Below is the crash stack for reference:
[ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: eventsunbound asyncrunentryfn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dmafreeattrs+0x5f/0x7d [ 428.469320] ath10kcorestop+0x5b/0x6f [ 428.469336] ath10khalt+0x126/0x177 [ 428.469352] ath10kstop+0x41/0x7e [ 428.469387] drvstop+0x88/0x10e [ 428.469410] ieee80211suspend+0x297/0x411 [ 428.469441] rdevsuspend+0x6e/0xd0 [ 428.469462] wiphysuspend+0xb1/0x105 [ 428.469483] ? nameshow+0x2d/0x2d [ 428.469490] dpmruncallback+0x8c/0x126 [ 428.469511] ? nameshow+0x2d/0x2d [ 428.469517] devicesuspend+0x2e7/0x41b [ 428.469523] asyncsuspend+0x1f/0x93 [ 428.469529] asyncrunentryfn+0x3d/0xd1 [ 428.469535] processonework+0x1b1/0x329 [ 428.469541] workerthread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? prcontwork+0x58/0x58 [ 428.469558] ? kthreadblkcg+0x31/0x31
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix channel survey memory allocation size
KASAN reported a memory allocation issue in wcn->chansurvey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chansurvey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.
In the Linux kernel, the following vulnerability has been resolved:
hisiaccvfiopci: bugfix live migration function without VF device driver
If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.
Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Add hashkeylength check
Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.
In the Linux kernel, the following vulnerability has been resolved:
firmware: armscmi: Fix list protocols enumeration in the base protocol
While enumerating protocols implemented by the SCMI platform using BASEDISCOVERLISTPROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loopnumret' is big enough.
Fix the validation avoiding the addition.
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: char: Fix use-after-free on probe error path
rpmsgchrdevprobe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsgchrdeveptdevadd(). If rpmsgchrdeveptdevadd() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer.
Avoid publishing eptdev through the default endpoint until rpmsgchrdeveptdevadd() succeeds. Messages received before the priv pointer is published should be ignored by rpmsgeptcb(). Flow-control updates can hit rpmsgeptflowcb() in the same window, so make both callbacks return success when priv is NULL.
A flaw was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size. This flaw may allow an attacker to information leak and cause a denial of service problem.
When the table perturb size is small, an attacker can practically cover all table cells with remote destinations to the attacker server, and the attacker may observe source port information.
Also, Global table perturb is shared across network interfaces and namespaces. This allows information to be leaked between interfaces.
Reference: https://kernel.googlesource.com/pub/scm/linux/kernel/git/jkirsher/net-queue/+/b2d057560b8107c633b39aabe517ff9d93f285e3%5E%21/
In the Linux kernel, the following vulnerability has been resolved:
mm: hugememory: don't force huge page alignment on 32 bit
commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace.
It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space.
[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
A flaw memory leak in the Linux Kernel XDP (eXpress Data Path) was found. It can lead to denial of service for some specific configurations like if the non root privileged user from the host system can send malicious packets to the guest systems. This flaw actual for the Linux Kernel versions 5.9 - 5.18.
References: https://www.openwall.com/lists/oss-security/2022/07/05/5 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/xen-netfront.c?h=v5.19-rc7&id=f63c2c2032c2e3caad9add3b82cc6e91c376fd26
A race condition was found in the Linux kernel's watch queue due to a missing lock in piperesizering(). The race condition may happen when thread (A) uses ioctl(IOCWATCHQUEUESETSIZE) to resize the pipe buffer and free the old pipe buffer, while another thread (B) uses keyctl() to trigger a notification in the watch queue, calling postonenotification() and accessing the freed pipe buffer.
ZDI advisory: https://www.zerodayinitiative.com/advisories/ZDI-22-1165/
Upstream fix: https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a
Last updated 24 July 2024
In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio/akcipher - Fix stack overflow on memcpy
sizeof(struct virtiocryptoakciphersessionpara) is less than sizeof(struct virtiocryptoopctrlreq::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtiocryptoakcipheralgs.o
crypto: arm64/neonbs - fix out-of-bounds access on short input
In the Linux kernel, the following vulnerability has been resolved:
usb: ulpi: Fix debugfs directory leak
The Linux kernel CVE team has assigned CVE-2024-26919 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041738-CVE-2024-26919-5100@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
peci: cpu: Fix use-after-free in adevrelease()
When auxiliarydeviceadd() returns an error, auxiliarydeviceuninit() is called, which causes refcount for device to be decremented and .release callback will be triggered.
Because adevrelease() re-calls auxiliarydeviceuninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcountwarnsaturate+0x110/0x15 [ 1269.464007] refcountt: underflow; use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
bpf: support deferring bpflink dealloc to after RCU grace period
BPF link for some program types is passed as a "context" which can be used by those BPF programs to look up additional information. E.g., for multi-kprobes and multi-uprobes, link is used to fetch BPF cookie values.
Because of this runtime dependency, when bpflink refcnt drops to zero there could still be active BPF programs running accessing link data.
This patch adds generic support to defer bpflink dealloc callback to after RCU GP, if requested. This is done by exposing two different deallocation callbacks, one synchronous and one deferred. If deferred one is provided, bpflinkfree() will schedule deallocdeferred() callback to happen after RCU GP.
BPF is using two flavors of RCU: "classic" non-sleepable one and RCU tasks trace one. The latter is used when sleepable BPF programs are used. bpflinkfree() accommodates that by checking underlying BPF program's sleepable flag, and goes either through normal RCU GP only for non-sleepable, or through RCU tasks trace GP and then normal RCU GP (taking into account rcutraceimpliesrcugp() optimization), if BPF program is sleepable.
We use this for multi-kprobe and multi-uprobe links, which dereference link during program run. We also preventively switch rawtp link to use deferred dealloc callback, as upcoming changes in bpf-next tree expose rawtp link data (specifically, cookie value) to BPF program at runtime as well.