In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Remove WO permissions on second-level paging entries
When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.
In the Linux kernel, the following vulnerability has been resolved:
ath10k: Fix a use after free in ath10khtcsendbundle
In ath10khtcsendbundle, the bundleskb could be freed by devkfreeskbany(bundleskb). But the bundleskb is used later by bundleskb->len.
As skblen = bundleskb->len, my patch replaces bundleskb->len to skblen after the bundleskb was freed.
In multiple locations, there is a possible memory corruption due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
In ioaddbuffers of iouring.c, there is a possible out of bounds write due to an incorrect bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.
bpf: Fix incorrect pruning due to atomic fetch precision tracking
In the Linux kernel, the following vulnerability has been resolved:
net: qrtr: Avoid potential use after free in MHI send
It is possible that the MHI ulcallback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb.
As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount..
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Use after free in vmbusopen()
The "openinfo" variable is added to the &vmbusconnection.chnmsglist, but the error handling frees "openinfo" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Avoid creating sub-groups asynchronously
The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes.
The crash can be easily reproduced with the following commands:
# cd /sys/kernel/config/pciep/functions/pciepftest # for i in {1..20}; do mkdir test && rmdir test; done
BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfsregistergroup+0x3d/0x190 pciepfcfswork+0x41/0x110 processonework+0x18f/0x350 workerthread+0x25a/0x3a0
Fix this issue by using configfsadddefaultgroup() API which does not have the deadlock problem as configfsregistergroup() and does not require the delayed work handler.
[mani: slightly reworded the description and added stable list]
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Fix cwnd update ordering
After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdmapostrecvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately.
The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdmarepcreate() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ibpostrecv().
In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix port event handling on init
For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state.
The crash points to canceldelayedwork() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig.
The following is the crash which can be triggered:
[ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: presterapci(+) prestera uiopdrvgenirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: presterafwwq presterafwevtworkfn [presterapci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : getworkpool+0x48/0x60 [ 28.401442] lr : trytograbpending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] getworkpool+0x48/0x60 [ 28.495874] canceldelayedwork+0x38/0xb0 [ 28.500011] presteraporthandleevent+0x90/0xa0 [prestera] [ 28.505743] presteraevtrecv+0x98/0xe0 [prestera] [ 28.510683] presterafwevtworkfn+0x180/0x228 [presterapci] [ 28.516660] processonework+0x1e8/0x360 [ 28.520710] workerthread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] retfromfork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]---
In the Linux kernel, the following vulnerability has been resolved:
net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null
Fixes a NULL pointer derefence bug triggered from tap driver. When tapgetuser calls virtionethdrtoskb the skb->dev is null (in tap.c skb->dev is set after the call to virtionethdrtoskb) virtionethdrtoskb calls devparseheaderprotocol which needs skb->dev field to be valid.
The line that trigers the bug is in devparseheaderprotocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->headerops || !dev->headerops->parseprotocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax
Setting skb->dev before the call in tap.c fixes the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtionethdrtoskb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tapgetuser+0x3f1/0x540 [tap] tapsendmsg+0x56/0x362 [tap] ? gettxbufs+0xc2/0x1e0 [vhostnet] handletxcopy+0x114/0x670 [vhostnet] handletx+0xb0/0xe0 [vhostnet] handletxkick+0x15/0x20 [vhostnet] vhostworker+0x7b/0xc0 [vhost] ? vhostvringcallreset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: properly indicate failure when ending a failed write request
This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared.
Since we are in the failure leg of raid1endwriterequest, the request either needs to be retried (R1BIOWriteError) or failed (R1BIODegraded).
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash in qla2xxxmqueuecommand()
RIP: 0010:kmemcachefree+0xfa/0x1b0 Call Trace: qla2xxxmqueuecommand+0x2b5/0x2c0 [qla2xxx] scsiqueuerq+0x5e2/0xa40 blkmqtryissuedirectly+0x128/0x1d0 blkmqrequestissuedirectly+0x4e/0xb0
Fix incorrect call to free srb in qla2xxxmqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between transaction aborts and fsyncs leading to use-after-free
There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following:
BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanuptransaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in writeallsupers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfssynclog:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:mutexlock+0x139/0xa40 Code: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? btrfshandlefserror+0xde/0x146 [btrfs] ? btrfssynclog+0x7c1/0xf20 [btrfs] ? btrfssynclog+0x7c1/0xf20 [btrfs] btrfssynclog+0x7c1/0xf20 [btrfs] btrfssyncfile+0x40c/0x580 [btrfs] dofsync+0x38/0x70 x64sysfsync+0x10/0x20 dosyscall64+0x33/0x80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIGRAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dmzero dmsnapshot dmthinpool (...) ---[ end trace ee2f1b19327d791d ]---
The steps that lead to this crash are the following:
1) We are at transaction N;
2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync;
3) Task B is at btrfssynclog(), and has saved fsinfo->logroottree into a local variable named 'logroottree' at the top of btrfssynclog(). Task B is about to call writeallsupers(), but before that...
4) Task A calls btrfscommittransaction(), and after it sets the transaction state to TRANSSTATECOMMITSTART, an error happens before it w ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix vmflags for virtqueue doorbell mapping
The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VMPFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vmflags. With this patch, try to map doorbell via IOTLB will fail with bad address.
In the Linux kernel, the following vulnerability has been resolved:
ACPI: custommethod: fix potential use-after-free issue
In cmwrite(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cmwrite() will still try to access it.
Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: core: Fix invalid error returning in mhiqueue
mhiqueue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update.
So, since it's not an error but just delaying of doorbell update, there is no reason to return an error.
This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done.
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: Fix use after free in atomispalloccssstatbufs()
The "s3abuf" is freed along with all the other items on the "asd->s3astats" list. It leads to a double free and a use after free.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix a use after free in siwallocmr
Our code analyzer reported a UAF.
In siwallocmr(), it calls siwmraddmem(mr,..). In the implementation of siwmraddmem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xaalloccyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the errout branch of siwallocmr, and the freed mr->mem is used in siwmrdropmem(mr).
My patch moves "mr->mem = mem" behind the if (xaalloccyclic(..)<0) {} section, to avoid the uaf.
In the Linux kernel, the following vulnerability has been resolved:
media: aspeed: fix clock handling logic
Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below.
Enable eclk De-assert Video Engine reset 10ms delay Enable vclk
It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot.
To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clkunprepare call for a case when probe fails.
clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting.
In the Linux kernel, the following vulnerability has been resolved:
mm: memcontrol: slab: fix obtain a reference to a freeing memcg
Patch series "Use objcgroup APIs to charge kmem pages", v5.
Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of objcgroup. The new APIs introduce a struct objcgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup.
E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x8664 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup in the memory).
#!/bin/bash
cat /proc/cgroups | grep memory
cd /sys/fs/cgroup/memory echo 1 > memory.movechargeatimmigrate
for i in range{1..500} do mkdir kmemtest echo $$ > kmemtest/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo cat kmemtest/cgroup.procs > cgroup.procs rmdir kmemtest done
cat /proc/cgroups | grep memory
This patchset aims to make those kmem pages to drop the reference to memory cgroup by using the APIs of objcgroup. Finally, we can see that the number of the dying cgroups will not increase if we run the above test script.
This patch (of 7):
The rcureadlock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of cssget (which is in the refillstock when cached memcg changed) to memcg.
rcureadlock() memcg = objcgroupmemcg(old) memcgkmemuncharge(memcg) refillstock(memcg) if (stock->cached != memcg) // cssget can change the ref counter from 0 back to 1. cssget(&memcg->css) rcureadunlock()
This fix is very like the commit:
eefbfa7fd678 ("mm: memcg/slab: fix use after free in objcgroupcharge")
Fix this by holding a reference to the memcg which is passed to the memcgkmemuncharge() before calling memcgkmemuncharge().
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Always make an attempt to map eVMCS after migration
When enlightened VMCS is in use and nested state is migrated with vmxgetnestedstate()/vmxsetnestedstate() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvmvmxnestedstatehdr' and we can't read it from VP assist page because userspace may decide to restore HVX64MSRVPASSISTPAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmxsetnestedstate() raises KVMREQGETNESTEDSTATEPAGES request.
Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVMREQGETNESTEDSTATEPAGES on nested vmexit") added KVMREQGETNESTEDSTATEPAGES clearing to nestedvmxvmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nestedsyncvmcs12toshadow() reflects changes in VMCS12 to eVMCS.
As a band-aid, restore nestedgetevmcspage() when clearing KVMREQGETNESTEDSTATEPAGES in nestedvmxvmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVMREQGETNESTEDSTATEPAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmxsetnestedstate().
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Disable preemption when probing user return MSRs
Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU.
Opportunistically land the helper in common x86, SVM will use the helper in a future commit.
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-zynqmp-gqspi: fix use-after-free in zynqmpqspiexecop
When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue.
In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Always enable the clk on resume
In mtkiommuruntimeresume always enable the clk, even if m4udom is null. Otherwise the 'suspend' cb might disable the clk which is already disabled causing the warning:
[ 1.586104] infram4u already disabled [ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clkcoredisable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtksmilarbcomponentops) [ 1.598108] Modules linked in: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtksmilarbcomponentops) [ 1.617487] Hardware name: Google Elm (DT) [ 1.617491] Workqueue: pm pmruntimework [ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtksmilarbcomponentops)
[ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 1.659297] pc : clkcoredisable+0xb0/0xb8 [ 1.663475] lr : clkcoredisable+0xb0/0xb8 [ 1.667652] sp : ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 000000000000000a x20: ffff0000c0048500 [ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 0000000000000000 [ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0 [ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328 [ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298 [ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000 [ 1.750572] Call trace: [ 1.753010] clkcoredisable+0xb0/0xb8 [ 1.756840] clkcoredisablelock+0x24/0x40 [ 1.761105] clkdisable+0x20/0x30 [ 1.764501] mtkiommuruntimesuspend+0x88/0xa8 [ 1.769114] pmgenericruntimesuspend+0x2c/0x48 [ 1.773815] rpmcallback+0xe0/0x178 [ 1.777559] rpmcallback+0x24/0x88 [ 1.781041] rpmsuspend+0xdc/0x470 [ 1.784523] rpmidle+0x12c/0x170 [ 1.787831] pmruntimework+0xa8/0xc0 [ 1.791573] processonework+0x1e8/0x360 [ 1.795580] workerthread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] retfromfork+0x10/0x30 [ 1.806034] ---[ end trace 82402920ef64573b ]--- [ 1.810728] ------------[ cut here ]------------
In addition, we now don't need to enable the clock from the function mtkiommuhwinit since it is already enabled by the resume.
In the Linux kernel, the following vulnerability has been resolved:
iouring: fix overflows checks in provide buffers
Colin reported before possible overflow and sign extension problems in ioprovidebuffersprep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("iouring: fix providebuffers sign extension").
Do that with help of check<op>overflow helpers. And fix struct ioprovidebuf::len type, as it doesn't make much sense to keep it signed.
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix txrate reporting
Properly check rateinfo to fix unexpected reporting.
[ 1215.161863] Call trace: [ 1215.164307] cfg80211calculatebitrate+0x124/0x200 [cfg80211] [ 1215.170139] ieee80211supdatemetric+0x80/0xc0 [mac80211] [ 1215.175624] ieee80211txstatusext+0x508/0x838 [mac80211] [ 1215.181190] mt7915mcugetrxrate+0x28c/0x8d0 [mt7915e] [ 1215.186580] mt7915mactxfree+0x324/0x7c0 [mt7915e] [ 1215.191623] mt7915queuerxskb+0xa8/0xd0 [mt7915e] [ 1215.196582] mt76dmacleanup+0x7b0/0x11d0 [mt76] [ 1215.201276] napipoll+0x38/0xf8 [ 1215.204668] napiworkfn+0x40/0x80 [ 1215.208062] processonework+0x1fc/0x390 [ 1215.212062] workerthread+0x48/0x4d0 [ 1215.215715] kthread+0x120/0x128 [ 1215.218935] retfromfork+0x10/0x1c
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix off by one in hdmi14processtransaction()
The hdcpi2coffsets[] array did not have an entry for HDCPMESSAGEIDWRITECONTENTSTREAMTYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcpddc.c.
I also declared several of these arrays as having HDCPMESSAGEIDMAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-clt: destroy sysfs after removing session from active list
A session can be removed dynamically by sysfs interface "removepath" that eventually calls rtrscltremovepathfromsysfs function. The current rtrscltremovepathfromsysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list.
Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session.
For instance rtrscltrequest and getnextpathmininflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrscltsess before reading its stats")
This patch changes the rtrscltremovepathfromsysfs to remove the session from the active session list and then destroy the sysfs interfaces.
Each function still should check the session status because closing or error recovery paths can change the status.