In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR
When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:
Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]
Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: mhi: fix potential memory leak in ath11kmhiregister()
mhialloccontroller() allocates a memory space for mhictrl. When gets some error, mhictrl should be freed with mhifreecontroller(). But when ath11kmhireadaddrfromdt() fails, the function returns without calling mhifreecontroller(), which will lead to a memory leak.
We can fix it by calling mhifreecontroller() when ath11kmhireadaddrfromdt() fails.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=216456
loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:updatesitentry+0xa55/0x10b0 [f2fs] Call Trace: <TASK> f2fsdoreplaceblock+0xa98/0x1890 [f2fs] f2fsreplaceblock+0xeb/0x180 [f2fs] recoverdata+0x1a69/0x6ae0 [f2fs] f2fsrecoverfsyncdata+0x120d/0x1fc0 [f2fs] f2fsfillsuper+0x4665/0x61e0 [f2fs] mountbdev+0x2cf/0x3b0 legacygettree+0xed/0x1d0 vfsgettree+0x81/0x2b0 pathmount+0x47e/0x19d0 domount+0xce/0xf0 x64sysmount+0x12c/0x1a0 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd
If we enable CONFIGF2FSCHECKFS config, it will trigger a kernel panic instead of warning.
The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update.
This patch introduces a new flag DATAGENERICENHANCEUPDATE, w/ this flag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fsreplaceblock() to avoid inconsistent status.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: drop ISOEND frames received without prior ISOSTART
ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISOCONT branch of isorecv() guards against a missing ISOSTART by checking conn->rxlen before touching conn->rxskb, but ISOEND does not.
If a peer sends an ISOEND as the first packet on a fresh ISO connection, conn->rxskb is still NULL and conn->rxlen is zero, so skbput(conn->rxskb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this.
Mirror the ISOCONT check at the top of ISOEND so a stray end fragment is logged and dropped instead of crashing the host.
In the Linux kernel, the following vulnerability has been resolved:
spi: fix statistics allocation
The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.
Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).
In the Linux kernel, the following vulnerability has been resolved:
drm/logicvc: Fix device node reference leak in logicvcdrmconfigparse()
The logicvcdrmconfigparse() function calls ofgetchildbyname() to find the "layers" node but fails to release the reference, leading to a device node reference leak.
Fix this by using the free(devicenode) cleanup attribute to automatic release the reference when the variable goes out of scope.
In the Linux kernel, the following vulnerability has been resolved:
flexproportions: make fpropnewperiod() hardirq safe
Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race:
<timer fires> runtimersoftirq - we are in softirq context calltimerfn writeoutperiod fpropnewperiod writeseqcountbegin(&p->sequence);
<hardirq is raised> ... blkmqendrequest() blkupdaterequest() ext4endbio() folioendwriteback() wbwriteoutadd() fpropaddpercpumax() if (unlikely(maxfrac < FPROPFRACBASE)) { fpropfractionpercpu() seq = readseqcountbegin(&p->sequence); - sees odd sequence so loops indefinitely
Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe.
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix BUGON in cephbuildxattrsblob() due to stale blob size
The generic/642 test-case can reproduce the kernel crash:
[40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr cephconworkfn [40243.612715] RIP: 0010:cephbuildxattrsblob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] prepcap+0x3fd/0x4a0 [40243.628789] ? dorawspinunlock+0x4e/0xe0 [40243.629474] cephcheckcaps+0x46a/0xc80 [40243.630094] ? lockacquire+0x4a2/0x2650 [40243.630773] ? findheldlock+0x31/0x90 [40243.631347] ? handlecapgrant+0x79f/0x1060 [40243.632068] ? lockrelease+0xd9/0x300 [40243.632696] ? mutexunlockslowpath+0x3e/0x340 [40243.633429] ? lockrelease+0xd9/0x300 [40243.634052] handlecapgrant+0xcf6/0x1060 [40243.634745] cephhandlecaps+0x122b/0x2110 [40243.635415] mdsdispatch+0x5bd/0x2160 [40243.636034] ? cephconprocessmessage+0x65/0x190 [40243.636828] ? lockrelease+0xd9/0x300 [40243.637431] cephconprocessmessage+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] processmessage+0x16/0x1a0 [40243.639915] ? sgfreetable+0x39/0x90 [40243.640572] cephconv2tryread+0xf58/0x2120 [40243.641255] ? lockacquire+0xc8/0x300 [40243.641863] cephconworkfn+0x151/0x820 [40243.642493] processonework+0x22f/0x630 [40243.643093] ? processonework+0x254/0x630 [40243.643770] workerthread+0x1e2/0x400 [40243.644332] ? pfxworkerthread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? pfxkthread+0x10/0x10 [40243.646125] retfromfork+0x3f8/0x480 [40243.646752] ? pfxkthread+0x10/0x10 [40243.647316] ? pfxkthread+0x10/0x10 [40243.647919] retfromforkasm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intelraplmsr intelraplcommon inteluncorefrequencycommon skxedaccommon nfit kvmintel kvm irqbypass joydev ghashclmulniintel aesniintel rapl inputleds machid psmouse vga16fb serioraw vgastate floppy i2cpiix4 pataacpi bochs qemufwcfg i2csmbus schfqcodel rbd dmcrypt msr parportpc ppdev lp parport efipstore [40243.654766] ---[ end trace 0000000000000000 ]---
Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the requiredblobsize computation to before the buildxattrs() call, introducing a race.
buildxattrs() releases and reacquires icephlock during execution. In that window, handlecapgrant() may update ixattrs.blob with a newer MDS-provided blob and bump ixattrs.version. When bui ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtkethsoc: Reset prog ptr to oldprog in case of error in mtkxdpsetup()
Reset eBPF program pointer to oldprog and do not decrease its ref-count if mtkopen routine in mtkxdpsetup() fails.
In the Linux kernel, the following vulnerability has been resolved:
Input: mtk-pmic-keys - fix possible null pointer dereference
In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.
Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.
In the Linux kernel, the following vulnerability has been resolved:
PCI: brcmstb: Fix error path after a call to regulatorbulkget()
If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.
If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.
While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().
[kwilczynski: commit log, use comma in the message to match style with other similar messages]
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Fix idafree call while not allocated
In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before idaalloc is called.
In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from warn+0x80/0x12c [ 4.260134] warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc
Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.
A race condition was found in the Linux kernel's scsi device driver in lpfcunregisterfcfrescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
In the Linux kernel, the following vulnerability has been resolved:
spi: s3c64xx: fix NULL-deref on driver unbind
A change moving DMA channel allocation from probe() back to s3c64xxspipreparetransfer() failed to remove the corresponding deallocation from remove().
Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind.
This issue was flagged by Sashiko when reviewing a controller deregistration fix.
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500/oaktraillvds: fix hang on init failure
The LVDS init code looks up an I2C adapter using i2cgetadapter() and tries to read the EDID before falling back to allocating and registering its own adapter.
The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2cgetadapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released.
Fix this by only destroying adapters allocated during LVDS init on errors.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED
[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.
The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(ininterrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.
[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.
(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.
[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxecomp.c:756 rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.617744] Modules linked in: rnbdclient(O) rtrsclient(O) rtrscore(O) rdmaucm rdmacm iwcm ibcm crc32generic rdmarxe ip6udptunnel udptunnel ibuverbs ibcore loop brd nullblk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? warn+0x79/0xc0 [ 920.624116] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.624356] ? reportbug+0xfb/0x150 [ 920.624594] ? handlebug+0x3c/0x60 [ 920.624796] ? excinvalidop+0x14/0x70 [ 920.624976] ? asmexcinvalidop+0x16/0x20 [ 920.625203] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.625474] ? rxecompleter+0x329/0xcc0 [rdmarxe] [ 920.625749] rxedotask+0x80/0x110 [rdmarxe] [ 920.626037] rxerequester+0x625/0xde0 [rdmarxe] [ 920.626310] ? rxecqpost+0xe2/0x180 [rdmarxe] [ 920.626583] ? docomplete+0x18d/0x220 [rdmarxe] [ 920.626812] ? rxecompleter+0x1a3/0xcc0 [rdmarxe] [ 920.627050] rxedotask+0x80/0x110 [rdmarxe] [ 920.627285] taskletactioncommon.constprop.0+0xa4/0x120 [ 920.627522] handlesoftirqs+0xc2/0x250 [ 920.627728] ? sortrange+0x20/0x20 [ 920.627942] runksoftirqd+0x1f/0x30 [ 920.628158] smpbootthreadfn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthreadcompleteandexit+0x20/0x20 [ 920.628709] retfromfork+0x1f/0x30 [ 920.628892] </TASK>
In the Linux kernel, the following vulnerability has been resolved:
OPP: fix devpmoppfindbw() when bandwidth table not initialized
If a driver calls devpmoppfindbwceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbwceil+0x50/0x88 ...
In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hciconn: Fix crash on hcicreatecissync
When attempting to connect multiple ISO sockets without using DEFERSETUP may result in the following crash:
BUG: KASAN: null-ptr-deref in hcicreatecissync+0x18b/0x2b0 Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50
CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted 6.0.0-rc7-02243-gb84a13ff4eda #4373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x19/0x27 kasanreport+0xbc/0xf0 ? hcicreatecissync+0x18b/0x2b0 hcicreatecissync+0x18b/0x2b0 ? getlinkmode+0xd0/0xd0 ? wwmutexlockslowpath+0x10/0x10 ? mutexlock+0xe0/0xe0 ? getlinkmode+0xd0/0xd0 hcicmdsyncwork+0x111/0x190 processonework+0x427/0x650 workerthread+0x87/0x750 ? processonework+0x650/0x650 kthread+0x14e/0x180 ? kthreadexit+0x50/0x50 retfromfork+0x22/0x30 </TASK>
cifs: Fix integer overflow while processing closetimeo mount option
In the Linux kernel, the following vulnerability has been resolved:
soc: mediatek: svs: Fix memory leak in svsenabledebugwrite()
In svsenabledebugwrite(), the buf allocated by memdupusernul() is leaked if kstrtoint() fails.
Fix this by using free(kfree) to automatically free buf, eliminating the need for explicit kfree() calls and preventing leaks.
[Angelo: Added missing cleanup.h inclusion]
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix a resource leak in xfsallocbuftarg()
In the error path, call fsputdax() to drop the DAX device reference.
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: add a sanity check on previous kernel's ima kexec buffer
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) – not-present page
Other architectures already validate the range with pageisram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Without carrying the measurement list across kexec, the attestation would fail.
In the Linux kernel, the following vulnerability has been resolved:
ima: verify the previous kernel's IMA buffer lies in addressable RAM
Patch series "Address page fault in imarestoremeasurementlist()", v3.
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) not-present page
This happens on x8664 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds")
This patch (of 3):
When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore.
Introduce a small generic helper, imavalidaterange(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfnrangeismapped(). - On OF based architectures, use pageisram().
In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Extract user memory type in ioremapprot()
The only caller of ioremapprot() outside of the generic ioremap() implementation is genericaccessphys(), which passes a 'pgprott' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprott' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremapprot() which faults when accessed from the kernel on systems with PAN:
| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | memcpyfromio+0x80/0xf8 | genericaccessphys+0x20c/0x2b8 | accessremotevm+0x46c/0x5b8 | accessremotevm+0x18/0x30 | environread+0x238/0x3e8 | vfsread+0xe4/0x2b0 | ksysread+0xcc/0x178 | arm64sysread+0x4c/0x68
Extract only the memory type from the user 'pgprott' in ioremapprot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps ioremapprot().
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}keysizeset() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000getfrequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
A race condition was found in the Linux kernel's net/bluetooth in sniff{min,max}intervalset() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
A race condition was found in the Linux kernel's media/dvb-core in dvbdmxwrite() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}{min,max}intervalset() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.