dm-stripe: fix a possible integer overflow

In the Linux kernel, the following vulnerability has been resolved:

mm/smaps: fix race between smapshugetlbrange and migration

smapshugetlbrange() handles the pte without holdling ptl, and may be concurrenct with migration, leaing to BUGON in pfnswapentrytopage(). The race is as follows.

smapshugetlbrange migratepages hugeptepget removemigrationptes foliounlock pfnswapentryfolio BUGON

To fix it, hold ptl lock in smapshugetlbrange().

drm/amd/display: fix a Null pointer dereference vulnerability

drm/amd/pm: fix null pointer access

In the Linux kernel, the following vulnerability has been resolved:

s390/mm: Fix inatomic() handling in dosecurestorageaccess()

Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen:

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 419074, name: qemu-system-s39 preemptcount: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copypagefromiteratomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dumpstacklvl+0xa2/0xe8 [<00000383e99bf152>] mightresched+0x292/0x2d0 [<00000383eaa7c374>] downread+0x34/0x2d0 [<00000383e99432f8>] dosecurestorageaccess+0x108/0x360 [<00000383eaa724b0>] dopgmcheck+0x130/0x220 [<00000383eaa842e4>] pgmcheckhandler+0x114/0x160 [<00000383ea47d028>] copypagefromiteratomic+0x128/0x8a0 ([<00000383ea47d016>] copypagefromiteratomic+0x116/0x8a0) [<00000383e9c45eae>] genericperformwrite+0x16e/0x310 [<00000383e9eb87f4>] ext4bufferedwriteiter+0x84/0x160 [<00000383e9da0de4>] vfswrite+0x1c4/0x460 [<00000383e9da123c>] ksyswrite+0x7c/0x100 [<00000383eaa7284e>] dosyscall+0x15e/0x280 [<00000383eaa8417e>] systemcall+0x6e/0x90 INFO: lockdep is turned off.

It is not allowed to take the mmaplock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page).

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: b53: do not enable EEE on bcm63xx

BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers.

Fix this by checking if the switch actually supports EEE before attempting to configure it.

In the Linux kernel, the following vulnerability has been resolved:

kasan: avoid sleepable page allocation from atomic context

applytopterange() enters the lazy MMU mode and then invokes kasanpopulatevmallocpte() callback on each page table walk iteration. However, the callback can go into sleep when trying to allocate a single page, e.g. if an architecutre disables preemption on lazy MMU mode enter.

On s390 if make archenterlazymmumode() -> preemptenable() and archleavelazymmumode() -> preemptdisable(), such crash occurs:

[ 0.663336] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321 [ 0.663348] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 2, name: kthreadd [ 0.663358] preemptcount: 1, expected: 0 [ 0.663366] RCU nest depth: 0, expected: 0 [ 0.663375] no locks held by kthreadd/2. [ 0.663383] Preemption disabled at: [ 0.663386] [<0002f3284cbb4eda>] applytopterange+0xfa/0x4a0 [ 0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT [ 0.663408] Hardware name: IBM 3931 A01 701 (KVM/Linux) [ 0.663409] Call Trace: [ 0.663410] [<0002f3284c385f58>] dumpstacklvl+0xe8/0x140 [ 0.663413] [<0002f3284c507b9e>] mightresched+0x66e/0x700 [ 0.663415] [<0002f3284cc4f6c0>] allocfrozenpagesnoprof+0x370/0x4b0 [ 0.663419] [<0002f3284ccc73c0>] allocpagesmpol+0x1a0/0x4a0 [ 0.663421] [<0002f3284ccc8518>] allocfrozenpagesnoprof+0x88/0xc0 [ 0.663424] [<0002f3284ccc8572>] allocpagesnoprof+0x22/0x120 [ 0.663427] [<0002f3284cc341ac>] getfreepagesnoprof+0x2c/0xc0 [ 0.663429] [<0002f3284cceba70>] kasanpopulatevmallocpte+0x50/0x120 [ 0.663433] [<0002f3284cbb4ef8>] applytopterange+0x118/0x4a0 [ 0.663435] [<0002f3284cbc7c14>] applytopmdrange+0x194/0x3e0 [ 0.663437] [<0002f3284cbc99be>] applytopagerange+0x2fe/0x7a0 [ 0.663440] [<0002f3284cbc9e88>] applytopagerange+0x28/0x40 [ 0.663442] [<0002f3284ccebf12>] kasanpopulatevmalloc+0x82/0xa0 [ 0.663445] [<0002f3284cc1578c>] allocvmaparea+0x34c/0xc10 [ 0.663448] [<0002f3284cc1c2a6>] getvmareanode+0x186/0x2a0 [ 0.663451] [<0002f3284cc1e696>] vmallocnoderangenoprof+0x116/0x310 [ 0.663454] [<0002f3284cc1d950>] vmallocnodenoprof+0xd0/0x110 [ 0.663457] [<0002f3284c454b88>] allocthreadstacknode+0xf8/0x330 [ 0.663460] [<0002f3284c458d56>] duptaskstruct+0x66/0x4d0 [ 0.663463] [<0002f3284c45be90>] copyprocess+0x280/0x4b90 [ 0.663465] [<0002f3284c460940>] kernelclone+0xd0/0x4b0 [ 0.663467] [<0002f3284c46115e>] kernelthread+0xbe/0xe0 [ 0.663469] [<0002f3284c4e440e>] kthreadd+0x50e/0x7f0 [ 0.663472] [<0002f3284c38c04a>] retfromfork+0x8a/0xf0 [ 0.663475] [<0002f3284ed57ff2>] retfromfork+0xa/0x38

Instead of allocating single pages per-PTE, bulk-allocate the shadow memory prior to applying kasanpopulatevmallocpte() callback on a page range.

In the Linux kernel, the following vulnerability has been resolved:

sfc: fix NULL dereferences in ef100processdesignparam()

Since cited commit, ef100probemain() and hence also ef100checkdesignparams() run before efx->netdev is created; consequently, we cannot netifsettsomaxsize() or segs() at this point. Move those netif calls to ef100probenetdev(), and also replace netiferr within the design params code with pcierr.

fs/9p: fix NULL pointer dereference on mkdir

In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels

Some lwtunnels have a dst cache for post-transformation dst. If the packet destination did not change we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed.

Discovered by the ioam6.sh test, kmemleak was recently fixed to catch per-cpu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not.

In the Linux kernel, the following vulnerability has been resolved:

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

In the Linux kernel, the following vulnerability has been resolved:

PCI: imx6: Fix suspend/resume support on i.MX6QDL

The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723):

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit:

https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995

Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices.

Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver:

ath10kpci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944

Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected.

[kwilczynski: commit log, added tag for stable releases]

In the Linux kernel, the following vulnerability has been resolved:

virtiofs: use pages instead of pointer for kernel direct IO

When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/pagealloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:allocpages+0x2bf/0x380 ...... Call Trace: <TASK> ? warn+0x8e/0x150 ? allocpages+0x2bf/0x380 kmalloclargenode+0x86/0x160 kmalloc+0x33c/0x480 virtiofsenqueuereq+0x240/0x6d0 virtiofswakependingandunlock+0x7f/0x190 queuerequestandunlock+0x55/0x60 fusesimplerequest+0x152/0x2b0 fusedirectio+0x5d2/0x8c0 fusefilereaditer+0x121/0x160 kernelread+0x151/0x2d0 kernelread+0x45/0x50 kernelreadfile+0x1a9/0x2a0 initmodulefromfile+0x6a/0xe0 idempotentinitmodule+0x175/0x230 x64sysfinitmodule+0x5d/0xb0 x64syscall+0x1c3/0x9e0 dosyscall64+0x3d/0xc0 entrySYSCALL64afterhwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]---

The warning is triggered as follows:

1) syscall finitmodule() handles the module insertion and it invokes kernelreadfile() to read the content of the module first.

2) kernelreadfile() allocates a 10MB buffer by using vmalloc() and passes it to kernelread(). kernelread() constructs a kvec iter by using ioviterkvec() and passes it to fusefilereaditer().

3) virtio-fs disables the cache, so fusefilereaditer() invokes fusedirectio(). As for now, the maximal read size for kvec iter is only limited by fc->maxread. For virtio-fs, maxread is UINTMAX, so fusedirectio() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in outargs[0] of a fuse request and passes the fuse request to virtiofswakependingandunlock().

4) virtiofswakependingandunlock() uses virtiofsenqueuereq() to queue the request. Because virtiofs need DMA-able address, so virtiofsenqueuereq() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copyargstoargbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in allocpages():

if (WARNONONCEGFP(order > MAXPAGEORDER, gfp)) return NULL;

5) virtiofsenqueuereq() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finitmodule() will hang forever.

A feasible solution is to limit the value of maxread for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->maxwrite in kernel.

So instead of limiting both the values of maxread and maxwrite in kernel, introducing usepagesforkvecio in fuseconn and setting it as true in virtiofs. When usepagesforkvecio is enabled, fuse will use pages instead of pointer to pass the KVECIO data.

After switching to pages for KVECIO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}kernelvmaprange() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuseargspages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fusegetuserpages() for write operations and the invalidation in fusereleaseuserpages() for read operations.

It may seem necessary to introduce another fie ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

mm/hugememory: avoid PMD-size page cache if needed

xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAXPAGECACHEORDER by commit 099d90642a71 ("mm/filemap: make MAXPAGECACHEORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example.

[root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char argv) { const char filename = TESTXFSFILENAME; int fd = 0; void buf = (void )-1, p; int pgsize = getpagesize(); int ret = 0;

if (pgsize != 0x10000) { fprintf(stdout, "System with 64KB base page size is required!\n"); return -EPERM; }

system("echo 0 > /sys/devices/virtual/bdi/253:0/readaheadkb"); system("echo 1 > /proc/sys/vm/dropcaches");

/ Open the xfs file / fd = open(filename, ORDONLY); assert(fd > 0);

/ Create VMA / buf = mmap(NULL, TESTMEMSIZE, PROTREAD, MAPSHARED, fd, 0); assert(buf != (void )-1); fprintf(stdout, "mapped buffer at 0x%p\n", buf);

/ Populate VMA / ret = madvise(buf, TESTMEMSIZE, MADVNOHUGEPAGE); assert(ret == 0); ret = madvise(buf, TESTMEMSIZE, MADVPOPULATEREAD); assert(ret == 0);

/ Collapse VMA / ret = madvise(buf, TESTMEMSIZE, MADVHUGEPAGE); assert(ret == 0); ret = madvise(buf, TESTMEMSIZE, MADVCOLLAPSE); if (ret) { fprintf(stdout, "Error %d to madvise(MADVCOLLAPSE)\n", errno); goto out; }

/ Split xarray entry. Write permission is needed / munmap(buf, TESTMEMSIZE); buf = (void )-1; close(fd); fd = open(filename, ORDWR); assert(fd > 0); fallocate(fd, FALLOCFLKEEPSIZE | FALLOCFLPUNCHHOLE, TESTMEMSIZE - pgsize, pgsize); out: if (buf != (void )-1) munmap(buf, TESTMEMSIZE); if (fd > 0) close(fd);

return ret; }

[root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test ------------[ cut here ]------------ WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset rfkill nftables nfnetlink vfat fat virtioballoon drm fuse \ xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 virtionet \ sha1ce netfailover virtioblk virtioconsole failover dimlib virtiommio CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xassplitalloc+0xf8/0x128 lr : splithugepagetolisttoorder+0x1c4/0x780 sp : ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8 x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xassplitalloc+0xf8/0x128 splithugepagetolisttoorder+0x1c4/0x780 truncateinodepartialfolio+0xdc/0x160 truncateinodepagesrange+0x1b4/0x4a8 truncatepagecacherange+0x84/0xa ---truncated---

HID: pidff: Make sure to fetch pool before checking SIMULTANEOUSMAX

block: fix race between setblocksize and read paths

In the Linux kernel, the following vulnerability has been resolved:

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

cgroup: split cgroupdestroywq into 3 workqueues

block: avoid possible overflow for chunksectors check in blkstacklimits()

In the Linux kernel, the following vulnerability has been resolved:

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

In the Linux kernel, the following vulnerability has been resolved:

x86/cpu/hygon: Add missing resctrlcpudetect() in bspinit helper

Since

923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrlcpudetect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.

This triggers a division by zero fault during early booting stage on our machines with X86FEATURECQM supported, where getrdtmonresources() tries to calculate monl3config with uninitialized bootcpudata.x86cacheoccscale.

Add the missing resctrlcpudetect() in the Hygon BSP init helper.

[ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

bpf: Reject narrower access to pointer ctx fields

In the Linux kernel, the following vulnerability has been resolved:

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

In the Linux kernel, the following vulnerability has been resolved:

serial: 8250: fix panic due to PSLVERR

When the PSLVERRRESPEN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.

In serial8250dostartup(), calling serialportout(port, UARTLCR, UARTLCRWLEN8) triggers dw8250checklcr(), which invokes dw8250forceidle() and serial8250clearandreinitfifos(). The latter function enables the FIFO via serialout(p, UARTFCR, p->fcr). Execution proceeds to the serialportin(port, UARTRX). This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UARTLCRSPAR) == (lcr & ~UARTLCRSPAR) in dw8250checklcr(), causing it to enter dw8250forceidle().

Put serialportout(port, UARTLCR, UARTLCRWLEN8) under the port->lock to fix this issue.

Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250serialin32+0x1e/0x4a [ 0.442351] ra : serial8250dostartup+0x2c8/0x88e ... [ 0.442416] consoleonrootfs+0x26/0x70