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

ksmbd: validate payload size in ipc response

If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.

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

smb: client: fix potential UAF in smb2isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

smb: client: guarantee refcounted children from parent session

Avoid potential use-after-free bugs when walking DFS referrals, mounting and performing DFS failover by ensuring that all children from parent @tcon->ses are also refcounted. They're all needed across the entire DFS mount. Get rid of @tcon->dfsseslist while we're at it, too.

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

smb: client: fix potential UAF in smb2isvalidleasebreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

smb: client: fix UAF in smb2reconnectserver()

The Linux kernel CVE team has assigned CVE-2024-35870 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051940-CVE-2024-35870-3c02@gregkh/T

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

smb: client: fix potential UAF in isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

smb: client: fix potential UAF in cifssignalcifsdforreconnect()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

NFSD: Fix nfsd4encodefattr4() crasher

Ensure that args.acl is initialized early. It is used in an unconditional call to kfree() on the way out of nfsd4encodefattr4().

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

Drivers: hv: vmbus: Track decrypted status in vmbusgpadl

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

In order to make sure callers of vmbusestablishgpadl() and vmbusteardowngpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbusgpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages.

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

Drivers: hv: vmbus: Leak pages if setmemoryencrypted() fails

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

VMBus code could free decrypted pages if setmemoryencrypted()/decrypted() fails. Leak the pages if this happens.

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

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipcbufappend() error path:

BUG: KASAN: slab-use-after-free in kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> dumpstack linux/lib/dumpstack.c:88 dumpstacklvl+0xd9/0x1b0 linux/lib/dumpstack.c:106 printaddressdescription linux/mm/kasan/report.c:377 printreport+0xc4/0x620 linux/mm/kasan/report.c:488 kasanreport+0xda/0x110 linux/mm/kasan/report.c:601 kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skbreleasedata+0x5af/0x880 linux/net/core/skbuff.c:1026 skbreleaseall linux/net/core/skbuff.c:1094 kfreeskb linux/net/core/skbuff.c:1108 kfreeskbreason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfreeskb linux/./include/linux/skbuff.h:1244 tipcbufappend+0x425/0xb50 linux/net/tipc/msg.c:186 tipclinkinput+0x224/0x7c0 linux/net/tipc/link.c:1324 tipclinkrcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipcrcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipcudprecv+0x73b/0x8f0 linux/net/tipc/udpmedia.c:390 udpqueuercvoneskb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udpqueuercvskb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udpunicastrcvskb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 udp4librcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ipprotocoldeliverrcu+0x30c/0x4e0 linux/net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2e4/0x520 linux/net/ipv4/ipinput.c:233 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iplocaldeliver+0x18e/0x1f0 linux/net/ipv4/ipinput.c:254 dstinput linux/./include/net/dst.h:461 iprcvfinish linux/net/ipv4/ipinput.c:449 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iprcv+0x2c5/0x5d0 linux/net/ipv4/ipinput.c:569 netifreceiveskbonecore+0x199/0x1e0 linux/net/core/dev.c:5534 netifreceiveskb+0x1f/0x1c0 linux/net/core/dev.c:5648 processbacklog+0x101/0x6b0 linux/net/core/dev.c:5976 napipoll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napipoll linux/net/core/dev.c:6645 netrxaction+0x95a/0xe90 linux/net/core/dev.c:6781 dosoftirq+0x21f/0x8e7 linux/kernel/softirq.c:553 dosoftirq linux/kernel/softirq.c:454 dosoftirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> localbhenableip+0x100/0x120 linux/kernel/softirq.c:381 localbhenable linux/./include/linux/bottomhalf.h:33 rcureadunlockbh linux/./include/linux/rcupdate.h:851 devqueuexmit+0x871/0x3ee0 linux/net/core/dev.c:4378 devqueuexmit linux/./include/linux/netdevice.h:3169 neighhhoutput linux/./include/net/neighbour.h:526 neighoutput linux/./include/net/neighbour.h:540 ipfinishoutput2+0x169f/0x2550 linux/net/ipv4/ipoutput.c:235 ipfinishoutput linux/net/ipv4/ipoutput.c:313 ipfinishoutput+0x49e/0x950 linux/net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 linux/net/ipv4/ipoutput.c:323 NFHOOKCOND linux/./include/linux/netfilter.h:303 ipoutput+0x13b/0x2a0 linux/net/ipv4/ipoutput.c:433 dstoutput linux/./include/net/dst.h:451 iplocalout linux/net/ipv4/ipoutput.c:129 ipsendskb+0x3e5/0x560 linux/net/ipv4/ipoutput.c:1492 udpsendskb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udpsendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inetsendmsg+0x105/0x140 linux/net/ipv4/afinet.c:850 socksendmsgnosec linux/net/socket.c:730 socksendmsg linux/net/socket.c:745 syssendto+0x42c/0x4e0 linux/net/socket.c:2191 dosyssendto linux/net/socket.c:2203 sesyssendto linux/net/socket.c:2199 x64syssendto+0xe0/0x1c0 linux/net/socket.c:2199 dosyscallx64 linux/arch/x86/entry/common.c:52 dosyscall ---truncated---

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

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disablestore(): usbhubtostructhub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems.

The same bug exists in the disableshow() routine, and it can be fixed the same way.

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

ksmbd: validate request buffer size in smb2allocaterspbuf()

The response buffer should be allocated in smb2allocaterspbuf before validating request. But the fields in payload as well as smb2 header is used in smb2allocaterspbuf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.

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

KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status

Check kvmmmupageadneedwriteprotect() when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU accounts for any role-specific reasons for disabling D-bit dirty logging.

Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled. KVM always disables PML when running L2, even when L1 and L2 GPAs are in the some domain, so failing to write-protect TDP MMU SPTEs will cause writes made by L2 to not be reflected in the dirty log.

[sean: massage shortlog and changelog, tweak ternary op formatting]

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

mlxsw: spectrumacltcam: Fix possible use-after-free during rehash

The Linux kernel CVE team has assigned CVE-2024-35854 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T

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

Bluetooth: btusb: mediatek: Fix double free of skb in coredump

hcidevcdappend() would free the skb on error so the caller don't have to free it again otherwise it would cause the double free of skb.

Reported-by : Dan Carpenter <dan.carpenter@linaro.org>

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

nfc: nci: Fix uninit-value in ncidevup and ncintfpacket

syzbot reported the following uninit-value access issue [1][2]:

ncirxwork() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.

This patch resolved this issue by checking payload size before calling each message type handler codes.

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. ismoduletextaddress() and moduletextaddress() works with MODULESTATELIVE and MODULESTATEGOING. If we use ismoduletextaddress() and moduletextaddress() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.

In checkkprobeaddresssafe(), if the second moduletextaddress() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated ismoduletextaddress() and moduletextaddress(), but use only moduletextaddress() once and do trymoduleget(module) which is only available with MODULESTATELIVE.

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

ksmbd: fix slab-out-of-bounds in smb2allocaterspbuf

If ->ProtocolId is SMB2TRANSFORMPROTONUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2queryinforeq), slab-out-of-bounds read can happen in smb2allocaterspbuf(). This patch allocate response buffer after decrypting transform request. smb3decryptreq() will validate transform request size and avoid slab-out-of-bound in smb2allocaterspbuf().

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

xen-netfront: Add missing skbmarkforrecycle

Notice that skbmarkforrecycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("pagepool: Allow drivers to hint on SKB recycling").

It is believed that fixes tag were missing a call to pagepoolreleasepage() between v5.9 to v5.14, after which is should have used skbmarkforrecycle(). Since v6.6 the call pagepoolreleasepage() were removed (in commit 535b9c61bdef ("net: pagepool: hide pagepoolreleasepage()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-pagepool-remove-pagepoolreleasepage'")).

This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/pagepool: catch pagepool memory leaks").

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

erspan: make sure erspanbasehdr is present in skb->head

syzbot reported a problem in ip6erspanrcv() [1]

Issue is that ip6erspanrcv() (and erspanrcv()) no longer make sure erspanbasehdr is present in skb linear part (skb->head) before getting @ver field from it.

Add the missing pskbmaypull() calls.

v2: Reload iph pointer in erspanrcv() after pskbmaypull() because skb->head might have changed.

[1]

BUG: KMSAN: uninit-value in pskbmaypullreason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskbmaypull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] BUG: KMSAN: uninit-value in grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 pskbmaypullreason include/linux/skbuff.h:2742 [inline] pskbmaypull include/linux/skbuff.h:2756 [inline] ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 ip6protocoldeliverrcu+0x1d4c/0x2ca0 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:460 [inline] ip6rcvfinish+0x955/0x970 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:314 [inline] ipv6rcv+0xde/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5538 [inline] netifreceiveskb+0x1da/0xa00 net/core/dev.c:5652 netifreceiveskbinternal net/core/dev.c:5738 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5798 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1549 tungetuser+0x5566/0x69e0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 tunallocskb drivers/net/tun.c:1525 [inline] tungetuser+0x209a/0x69e0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

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

idpf: fix kernel panic on unknown packet types

In the very rare case where a packet type is unknown to the driver, idpfrxprocessskbfields would return early without calling ethtypetrans to set the skb protocol / the network layer handler. This is especially problematic if tcpdump is running when such a packet is received, i.e. it would cause a kernel panic.

Instead, call ethtypetrans for every single packet, even when the packet type is unknown.

hvnetvsc: Don't free decrypted memory

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

netfilter: nftables: restore set elements when delete set fails

From abort path, nftmapelemactivate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).

This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.

Toggle next generation bit for elements when delete set command is invoked and call nftclear() from .activate (abort) path to restore the next generation bit.

The splat below shows an object in mappings memleak:

[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nftables.h:1237 nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [...] [43929.458014] RIP: 0010:nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? warn+0x9f/0x1a0 [43929.458127] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458188] ? reportbug+0x1b1/0x1e0 [43929.458196] ? handlebug+0x3c/0x70 [43929.458200] ? excinvalidop+0x17/0x40 [43929.458211] ? nftsetelemdatadeactivate+0xd7/0xf0 [nftables] [43929.458271] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458332] nftmapelemdeactivate+0x24/0x30 [nftables] [43929.458392] nftrhashwalk+0xdd/0x180 [nftables] [43929.458453] ? pfxnftrhashwalk+0x10/0x10 [nftables] [43929.458512] ? rbinsertcolor+0x2e/0x280 [43929.458520] nftmapdeactivate+0xdc/0x1e0 [nftables] [43929.458582] ? pfxnftmapdeactivate+0x10/0x10 [nftables] [43929.458642] ? pfxnftmapelemdeactivate+0x10/0x10 [nftables] [43929.458701] ? rcureadunlock+0x46/0x70 [43929.458709] nftdelset+0xff/0x110 [nftables] [43929.458769] nftflushtable+0x16f/0x460 [nftables] [43929.458830] nftablesdeltable+0x501/0x580 [nftables]

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

speakup: Avoid crash on very long word

In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.

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

crypto: iaa - Fix nrcpus < nriaa case

If nrcpus < nriaa, the calculated cpusperiaa will be 0, which causes a divide-by-0 in rebalancewqtable().

Make sure cpusperiaa is 1 in that case, and also in the nriaa == 0 case, even though cpusperiaa is never used if nriaa == 0, for paranoia.

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

x86/coco: Require seeding RNG with RDRAND on CoCo systems

The Linux kernel CVE team has assigned CVE-2024-35875 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051942-CVE-2024-35875-e23d@gregkh/T

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

arm64: tlb: Fix TLBI RANGE operand

KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvmtlbflushvmidrange()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed.

For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvmtlbflushvmidrange() is executed to flush TLBs. It passes MAXTLBIRANGEPAGES as the argument to kvmtlbflushvmidrange() and flushs2tlbrangeop(). SCALE#3 and NUM#31, corresponding to MAXTLBIRANGEPAGES, isn't supported by TLBIRANGENUM(). In this specific case, -1 has been returned from TLBIRANGENUM() for SCALE#3/2/1/0 and rejected by the loop in the flushtlbrangeop() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by TLBIVADDRRANGE() according to invalid @scale and @num.

Fix it by extending TLBIRANGENUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBIRANGEMASK is dropped since no one uses it any more. The comments are also adjusted accordingly.

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

riscv: Fix loading 64-bit NOMMU kernels past the start of RAM

commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") added logic to allow using RAM below the kernel load address. However, this does not work for NOMMU, where PAGEOFFSET is fixed to the kernel load address. Since that range of memory corresponds to PFNs below ARCHPFNOFFSET, mm initialization runs off the beginning of memmap and corrupts adjacent kernel memory. Fix this by restoring the previous behavior for NOMMU kernels.