In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Fix use-after-free in path file creation cleanup
In the error path of rtrssrvcreatepathfiles(), the sysfs root folders may already have been created and srvpath->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobjectput(&srvpath->kobj) before rtrssrvdestroyoncesysfsrootfolders(srvpath).
kobjectput() may drop the last reference to srvpath->kobj and invoke the release callback, rtrssrvrelease(), which frees srvpath. The following call to rtrssrvdestroyoncesysfsrootfolders(srvpath) then dereferences srvpath internally to access srvpath->srv, resulting in a use-after-free.
This failure path is reached before rtrssrvcreatepathfiles() returns success, so the successful-path lifetime handling is not involved.
Fix this by destroying the sysfs root folders before calling kobjectput(&srvpath->kobj), so srvpath is still valid while the helper accesses it.
This issue was found by a static analysis tool I am developing.
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:
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:
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:
In the Linux kernel, the following vulnerability has been resolved:
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:
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)
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