In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcicore: Disable works on hciunregisterdev
This make use of disablework on hciunregisterdev since the hcidev is about to be freed new submissions are not disarable.
In the Linux kernel, the following vulnerability has been resolved:
net: fix udp gso skbsegment after pull from fraglist
Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from fraglist") detected invalid geometry in fraglist skbs and redirects them from skbsegmentlist to more robust skbsegment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skbsegment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.
If only part of the fraglist payload is pulled into headskb, it will always cause exception when splitting skbs by skbsegment. For detailed call stack information, see below.
Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize
Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify fraglist skbs, breaking these invariants.
In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.
The skbs no longer meets the above SKBGSOFRAGLIST conditions because payload was pulled into headskb, it needs to be linearized before pass to regular skbsegment.
skbsegment+0xcd0/0xd14 udpgsosegment+0x334/0x5f4 udp4ufofragment+0x118/0x15c inetgsosegment+0x164/0x338 skbmacgsosegment+0xc4/0x13c skbgsosegment+0xc4/0x124 validatexmitskb+0x9c/0x2c0 validatexmitskblist+0x4c/0x80 schdirectxmit+0x70/0x404 devqueuexmit+0x64c/0xe5c neighresolveoutput+0x178/0x1c4 ipfinishoutput2+0x37c/0x47c ipfinishoutput+0x194/0x240 ipfinishoutput+0x20/0xf4 ipoutput+0x100/0x1a0 NFHOOK+0xc4/0x16c ipforward+0x314/0x32c iprcv+0x90/0x118 netifreceiveskb+0x74/0x124 processbacklog+0xe8/0x1a4 napipoll+0x5c/0x1f8 netrxaction+0x154/0x314 handlesoftirqs+0x154/0x4b8
[118.376811] [C201134] rxq0pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0pus: [name:mrdump&]PHYSOFFSET: 0x40000000 [118.470827] [C201134] rxq0pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0pus: [name:mrdump&]pc : [0xffffffd79598aefc] skbsegment+0xcd0/0xd14 [118.470900] [C201134] rxq0pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skbsegment+0x3bc/0xd14 [118.470928] [C201134] rxq0pus: [name:mrdump&]sp : ffffffc008013770
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: Fix packet corruption in vmxnet3xdpxmitframe
Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.
If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.
vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:
page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATODEVICE);
The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void )xdpf, that is, xdp->data - xdp->datahardstart.
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix possible UAF in sctpv6available()
A lockdep report [1] with CONFIGPROVERCULIST=y hints that sctpv6available() is calling devgetbyindexrcu() and ipv6chkaddr() without holding rcu.
[1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcuscheduleractive = 2, debuglocks = 1 1 lock held by sctphello/31495: #0: ffff9f1ebbdb7418 (sklock-AFINET6){+.+.}-{0:0}, at: sctpbind (./arch/x86/include/asm/jumplabel.h:27 net/sctp/socket.c:315) sctp
stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctphello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) lockdeprcususpicious (kernel/locking/lockdep.c:6822) devgetbyindexrcu (net/core/dev.c:876 (discriminator 7)) sctpv6available (net/sctp/ipv6.c:701) sctp sctpdobind (net/sctp/socket.c:400 (discriminator 1)) sctp sctpbind (net/sctp/socket.c:320) sctp inet6bindsk (net/ipv6/afinet6.c:465) ? securitysocketbind (security/security.c:4581 (discriminator 1)) sysbind (net/socket.c:1848 net/socket.c:1869) ? douseraddrfault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? douseraddrfault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) x64sysbind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0: 44 00 00 add %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W
Code starting with the faulting instruction =========================================== 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIGRAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIGBROKEN
Hide KVM's ptmode module param behind CONFIGBROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk.
For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and stays disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTITCTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM:
If the logical processor is operating with Intel PT enabled (if IA32RTITCTL.TraceEn = 1) at the time of VM entry, the "load IA32RTITCTL" VM-entry control must be 0.
On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.
drm/amd/display: Handle dml allocation failure to avoid crash
In the Linux kernel, the following vulnerability has been resolved:
bpf: synclinkedregs() must preserve subregdef
Range propagation must not affect subregdef marks, otherwise the following example is rewritten by verifier incorrectly when BPFFTESTRNDHI32 flag is set:
0: call bpfktimegetns call bpfktimegetns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit
(or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half).
The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subregdef is overridden at (3) by copyregisterstate(); - w1 is read at (5) but markinsnzext() does not mark (2) for zero extension, because w1 subregdef is not set; - because of BPFFTESTRNDHI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5).
In the Linux kernel, the following vulnerability has been resolved:
net: fix data-races around sk->skforwardalloc
Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---
Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()
In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0
The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().
In the Linux kernel, the following vulnerability has been resolved:
mptcp: cope racing subflow creation in mptcprcvspaceadjust
Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs.
A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcpcleanuprbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones.
Explicitly check that the subflow is in a suitable state before invoking tcpcleanuprbuf().
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fs, lock FTE when checking if active
The referenced commits introduced a two-step process for deleting FTEs:
- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.
However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fscore may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions.
To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fscore layer from attaching a new steering rule to an FTE that is in the process of deletion.
[ 438.967589] MOSHE: 2496 mlx5delflowrules delhwfunc [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcountt: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcountwarnsaturate+0xfb/0x110 [ 438.970054] Modules linked in: actmirred clsflower actgact schingress openvswitch nsh mlx5vdpa vringh vhostiotlb vdpa mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm ibuverbs ibcore zram zsmalloc fuse [last unloaded: clsflower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcountwarnsaturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? warn+0x7d/0x110 [ 438.987426] ? refcountwarnsaturate+0xfb/0x110 [ 438.987877] ? reportbug+0x17d/0x190 [ 438.988261] ? prbreadvalid+0x17/0x20 [ 438.988659] ? handlebug+0x53/0x90 [ 438.989054] ? excinvalidop+0x14/0x70 [ 438.989458] ? asmexcinvalidop+0x16/0x20 [ 438.989883] ? refcountwarnsaturate+0xfb/0x110 [ 438.990348] mlx5delflowrules+0x2f7/0x340 [mlx5core] [ 438.990932] mlx5eswitchdelrule+0x49/0x170 [mlx5core] [ 438.991519] ? mlx5lagissriov+0x3c/0x50 [mlx5core] [ 438.992054] ? xasload+0x9/0xb0 [ 438.992407] mlx5etcruleunoffload+0x45/0xe0 [mlx5core] [ 438.993037] mlx5etcdelfdbflow+0x2a6/0x2e0 [mlx5core] [ 438.993623] mlx5eflowput+0x29/0x60 [mlx5core] [ 438.994161] mlx5edeleteflower+0x261/0x390 [mlx5core] [ 438.994728] tcsetupcbdestroy+0xb9/0x190 [ 438.995150] flhwdestroyfilter+0x94/0xc0 [clsflower] [ 438.995650] flchange+0x11a4/0x13c0 [clsflower] [ 438.996105] tcnewtfilter+0x347/0xbc0 [ 438.996503] ? ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
In error flow of mlx5tcctentryaddrule(), in case ctruleadd() callback returns error, zonerule->attr is used uninitiated. Fix it to use attr which has the needed pointer value.
Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] … Call Trace: <TASK> ? die+0x20/0x70 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x140 ? asmexcpagefault+0x22/0x30 ? mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] ? mlx5tcctentryaddrule+0x1d5/0x2f0 [mlx5core] mlx5tcctblockflowoffload+0xc6a/0xf90 [mlx5core] ? nfflowoffloadtuple+0xd8/0x190 [nfflowtable] nfflowoffloadtuple+0xd8/0x190 [nfflowtable] flowoffloadworkhandler+0x142/0x320 [nfflowtable] ? finishtaskswitch.isra.0+0x15b/0x2b0 processonework+0x16c/0x320 workerthread+0x28c/0x3a0 ? pfxworkerthread+0x10/0x10 kthread+0xb8/0xf0 ? pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix address wraparound in movepagetables()
On 32-bit platforms, it is possible for the expression len + oldaddr < oldend to be false-positive if len + oldaddr wraps around. oldaddr is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, oldaddr is the end of the old region, and adding len to it can wrap.
The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed.
The idea of this check is that oldend - len is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly.
(An alternate fix would be to refactor this function by introducing an "origoldstart" variable or such.)
Tested in a VM with a 32-bit X86 kernel; without the patch:
user@horn:~/bigmremap$ cat test.c #define GNUSOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h>
#define ADDR1 ((void)0x60000000) #define ADDR2 ((void)0x10000000) #define SIZE 0x50000000uL
int main(void) { unsigned char p1 = mmap(ADDR1, SIZE, PROTREAD|PROTWRITE, MAPANONYMOUS|MAPPRIVATE|MAPFIXEDNOREPLACE, -1, 0); if (p1 == MAPFAILED) err(1, "mmap 1"); unsigned char p2 = mmap(ADDR2, SIZE, PROTNONE, MAPANONYMOUS|MAPPRIVATE|MAPFIXEDNOREPLACE, -1, 0); if (p2 == MAPFAILED) err(1, "mmap 2"); p1 = 0x41; printf("first char is 0x%02hhx\n", p1); unsigned char p3 = mremap(p1, SIZE, SIZE, MREMAPMAYMOVE|MREMAPFIXED, p2); if (p3 == MAPFAILED) { printf("mremap() failed; first char is 0x%02hhx\n", p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", p3); } } user@horn:~/bigmremap$ gcc -static -o test test.c user@horn:~/bigmremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00
With the patch:
user@horn:~/bigmremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41
In the Linux kernel, the following vulnerability has been resolved:
vpvdpa: fix idtable array not null terminated error
Allocate one extra virtiodeviceid as null terminator, otherwise vdpamgmtdevgetclasses() may iterate multiple times and visit undefined memory.
In the Linux kernel, the following vulnerability has been resolved:
nommu: pass NULL argument to vmaiterprealloc()
When deleting a vma entry from a maple tree, it has to pass NULL to vmaiterprealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acctcollect() reading the size of vma entries after domunmap().
This commit fixes this issue by passing a right argument to the preallocation call.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Adjust VSDB parser for replay feature
At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN:
[ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpudmupdatefreesynccaps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383
...
[ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ==================================================================
This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amdvsdbblock size.
(cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)
In the Linux kernel, the following vulnerability has been resolved:
ima: fix buffer overrun in imaeventdigestinitcommon
Function imaeventdigestinit() calls imaeventdigestinitcommon() with HASHALGOLAST which is then used to access the array hashdigestsize[] leading to buffer overrun. Have a conditional statement to handle this.
In the Linux kernel, the following vulnerability has been resolved:
fs/proc/taskmmu: prevent integer overflow in pagemapscangetargs()
The "arg->veclen" variable is a u64 that comes from the user at the start of the function. The "arg->veclen sizeof(struct pageregion))" multiplication can lead to integer wrapping. Use sizemul() to avoid that.
Also the sizeadd/mul() functions work on unsigned long so for 32bit systems we need to ensure that "arg->veclen" fits in an unsigned long.
In the Linux kernel, the following vulnerability has been resolved:
hvsock: Initializing vsk->trans to NULL to prevent a dangling pointer
When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.
In the Linux kernel, the following vulnerability has been resolved:
nvme: tcp: avoid race between queuelock lock and destroy
Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutexlock() call for the queue->queuelock in nvmetcpgetaddress(). However, the mutexlock() races with mutexdestroy() in nvmetcpfreequeue(), and causes the WARN below.
DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 mutexlock+0xcf0/0x1220 Modules linked in: nvmettcp nvmet nvmetcp nvmefabrics iwcm ibcm ibcore pktcdvd nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables qrtr sunrpc ppdev 9pnetvirtio 9pnet pcspkr netfs parportpc parport e1000 i2cpiix4 i2csmbus loop fuse nfnetlink zram bochs drmvramhelper drmttmhelper ttm drmkmshelper xfs drm sym53c8xx floppy nvme scsitransportspi nvmecore nvmeauth serioraw atageneric pataacpi dmmultipath qemufwcfg [last unloaded: ibuverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mutexlock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn.cold+0x5b/0x1af ? mutexlock+0xcf0/0x1220 ? reportbug+0x1ec/0x390 ? handlebug+0x3c/0x80 ? excinvalidop+0x13/0x40 ? asmexcinvalidop+0x16/0x20 ? mutexlock+0xcf0/0x1220 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxmutexlock+0x10/0x10 ? lockacquire+0xd6a/0x59e0 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxnvmetcpgetaddress+0x10/0x10 [nvmetcp] nvmesysfsshowaddress+0x81/0xc0 [nvmecore] devattrshow+0x42/0x80 ? asanmemset+0x1f/0x40 sysfskfseqshow+0x1f0/0x370 seqreaditer+0x2cb/0x1130 ? rwverifyarea+0x3b1/0x590 ? mutexlock+0x433/0x1220 vfsread+0x6a6/0xa20 ? lockdephardirqson+0x78/0x100 ? pfxvfsread+0x10/0x10 ksysread+0xf7/0x1d0 ? pfxksysread+0x10/0x10 ? x64sysopenat+0x105/0x1d0 dosyscall64+0x93/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? pfxksysread+0x10/0x10 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? dosyscall64+0x9f/0x180 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---
bpf: Check validity of link->type in bpflinkshowfdinfo()
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/ufence: Prefetch ufence addr to catch bogus address
accessok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace.
(cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)
In the Linux kernel, the following vulnerability has been resolved:
mm: resolve faulty mmapregion() error path behaviour
The mmapregion() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.
A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.
Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function mmapregion().
Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIGDEBUGVMMAPLETREE validation unconditionally also.
We move a number of things here:
1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.
2. The enclosing mmapregion() function handles the mappingmapwritable() logic early. Previously the logic had the mappingmapwritable() at the point of mapping a newly allocated file-backed VMA, and a matching mappingunmapwritable() on success and error paths.
We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VMMAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.
We perform a debug assert to ensure a driver does not attempt to do the opposite.
3. We also move archvalidateflags() up into the mmapregion() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.
With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.
This eliminates an entire class of errors, makes the code easier to reason about and more robust.
In the Linux kernel, the following vulnerability has been resolved:
virtiopci: Fix admin vq cleanup by using correct info pointer
vpmodernavqcleanup() and vpdelvqs() clean up admin vq resources by virtiopcivqinfo pointer. The info pointer of admin vq is stored in vpdev->adminvq.info instead of vpdev->vqs[]. Using the info pointer from vpdev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vpmodernavqcleanup() and vpdelvqs(), get the info pointer from vpdev->adminvq.info for admin vq to clean up the resources. Also make info ptr as argument of vpdelvq() to be symmetric with vpsetupvq().
vpreset calls vpmodernavqcleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vpreset+0x57/0x90 [virtiopci] Call Trace: <TASK> ... ? vpreset+0x57/0x90 [virtiopci] ? vpreset+0x38/0x90 [virtiopci] virtioresetdevice+0x1d/0x30 removevqcommon+0x1c/0x1a0 [virtionet] virtnetremove+0xa1/0xc0 [virtionet] virtiodevremove+0x46/0xa0 ... virtiopcidriverexit+0x14/0x810 [virtiopci] ==================================================================
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: defer partition scanning
We need to suppress the partition scan from occuring within the controller's scanwork context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scanwork, so it would deadlock. Defer the partion scan to a different context that does not block scanwork.
bpf: Add skisinet and ISICSK check in tlsswhasctxtx/rx
afs: Fix lock recursion
i40e: fix race condition by adding filter's intermediate sync state
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Add hashkeylength check
Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.
In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Lock XArray when getting entries for the VM
Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there.
v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.
In the Linux kernel, the following vulnerability has been resolved:
mm/thp: fix deferred split unqueue naming and locking
Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing listdel corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.
Before fixing locking: rename misleading folioundolargermappable(), which does not undo largermappable, to foliounqueuedeferredsplit(), which is what it does. But that and its out-of-line callee are mm internals of very limited usability: add comment and WARNONONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARNONONCEs around safety checks (sparing callers the arcane conditionals in foliounqueuedeferredsplit()).
Just omit the foliounqueuedeferredsplit() from freeunreffolios(), all of whose callers now call it beforehand (and if any forget then badpage() will tell) - except for its caller putpageslist(), which itself no longer has any callers (and will be deleted separately).
Swapout: memcgroupswapout() has been resetting folio->memcgdata 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the splitqueuelock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. removemapping() has frozen refcount to 0 here, so no problem with calling foliounqueuedeferredsplit() before resetting memcgdata.
That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace.
Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment.
Memcg-v1 move (deprecated): memcgroupmoveaccount() has been changing folio->memcgdata without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so foliounqueuedeferredsplit() can only be used in a WARNONONCE to validate the fix, which must be done earlier: memcgroupmovechargepterange() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case.
The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false.
Backport to 6.11 should be straightforward. Earlier backports must take care that other deferredlist fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.