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

spi: tegra210-quad: Protect currxfer check in IRQ handler

Now that all other accesses to currxfer are done under the lock, protect the currxfer NULL check in tegraqspiisrthread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->currxfer) // sees non-NULL spinlock() tqspi->currxfer = NULL spinunlock() handlexfer() spinlock() t = tqspi->currxfer // NULL! ... t->len ... // NULL dereference!

With this patch, all currxfer accesses are now properly synchronized.

Although all accesses to currxfer are done under the lock, in tegraqspiisrthread() it checks for NULL, releases the lock and reacquires it later in handlecpubasedxfer()/handledmabasedxfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared currxfer, the handler will safely return without dereferencing the NULL pointer.

btrfs: reject new transactions if the fs is fully read-only

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

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

shmem: fix recovery on rename failures

mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().

Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().

Not hard to fix, fortunately - mtreestore() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simpleoffsetrenameexchange() that's enough - we just need to be careful about the order of operations.

For simpleoffsetrename() solution is to preinsert the target into the tree for newdir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

btrfs: fix NULL dereference on root when tracing inode eviction

btrfs: always detect conflicting inodes when logging inode refs

bonding: annotate data-races around slave->lastrx

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

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:

ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s └── class 1:2 (weight=1, lmax=1514) teql

GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfqchangeclass calls qfqdeactrmfromagg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.

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

ceph: fix oops due to invalid pointer for kfree() in parselongname()

This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running ls /mnt/myceph/.snap.

The variable str is guarded by free(kfree), but advanced by one for skipping the initial '' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer.

Steps to reproduce:

1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)

2. Add cephfs mount to fstab $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,netdev 0 0" >> /etc/fstab

3. Reboot the system $ systemctl reboot

4. Check if it's really mounted $ mount | grep stuff

5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap

Now ls hangs forever and the kernel log shows the oops.

ALSA: aloop: Fix racy access at PCM trigger

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

of: unittest: Fix memory leak in unittestdataadd()

In unittestdataadd(), if ofresolvephandles() fails, the allocated unittestdata is not freed, leading to a memory leak.

Fix this by using scope-based cleanup helper free(kfree) for automatic resource cleanup. This ensures unittestdata is automatically freed when it goes out of scope in error paths.

For the success path, use retainandnullptr() to transfer ownership of the memory to the device tree and prevent double freeing.

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

cpuset: fix warning when disabling remote partition

A warning was triggered as follows:

WARNING: kernel/cgroup/cpuset.c:1651 at remotepartitiondisable+0xf7/0x110 RIP: 0010:remotepartitiondisable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: <TASK> updateprstate+0x2d3/0x580 cpusetpartitionwrite+0x94/0xf0 kernfsfopwriteiter+0x147/0x200 vfswrite+0x35d/0x500 ksyswrite+0x66/0xe0 dosyscall64+0x6b/0x390 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887

Reproduction steps (on a 16-CPU machine):

# cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtreecontrol # echo "0-14" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo "0-14" > A1/A2/cpuset.cpus.exclusive # echo "root" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition

When CPU 15 is offlined, subpartitionscpus gets cleared because no CPUs remain available for the topcpuset, forcing partitions to share CPUs with the topcpuset. In this scenario, disabling the remote partition triggers a warning stating that effectivexcpus is not a subset of subpartitionscpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with topcpuset).

To fix this issue: 1. Only emit the warning only if subpartitionscpus is not empty and the effectivexcpus is not a subset of subpartitionscpus. 2. During the CPU hotplug process, invalidate partitions if subpartitionscpus is empty.

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

wifi: iwlwifi: mld: cancel mloscanstartwk

mloscanstartwk is not canceled on disconnection. In fact, it is not canceled anywhere except in the restart cleanup, where we don't really have to.

This can cause an init-after-queue issue: if, for example, the work was queued and then drvchangeinterface got executed.

This can also cause use-after-free: if the work is executed after the vif is freed.

dst: fix races in rt6uncachedlistdel() and rtdeluncachedlist()

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

ALSA: usb-audio: Prevent excessive number of frames

bonding: fix use-after-free due to enslave fail after slave array update

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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net: fix segmentation of forwarding fraglist GRO

This patch enhances GSO segment handling by properly checking the SKBGSODODGY flag for fraglist GSO packets, addressing low throughput issues observed when a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface.

Specifically, it fixes a bug in GSO segmentation when forwarding GRO packets containing a fraglist. The function skbsegmentlist cannot correctly process GRO skbs that have been converted by XLAT, since XLAT only translates the header of the head skb. Consequently, skbs in the fraglist may remain untranslated, resulting in protocol inconsistencies and reduced throughput.

To address this, the patch explicitly sets the SKBGSODODGY flag for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers (bpfskbproto4to6 and bpfskbproto6to4). This marks GSO packets as potentially modified after protocol translation. As a result, GSO segmentation will avoid using skbsegmentlist and instead falls back to skbsegment for packets with the SKBGSODODGY flag. This ensures that only safe and fully translated fraglist packets are processed by skbsegmentlist, resolving protocol inconsistencies and improving throughput when forwarding GRO packets converted by XLAT.

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

iouring/io-wq: check IOWQBITEXIT inside work run loop

Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr file. Since this file type doesn't support ->readiter(), looprwiter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:

INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5256 [inline] schedule+0x1139/0x6150 kernel/sched/core.c:6863 scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalorrestart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98

There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.

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

netfilter: nftables: fix inverted genmask check in nftmapcatchallactivate()

nftmapcatchallactivate() has an inverted element activity check compared to its non-catchall counterpart nftmapelemactivate() and compared to what is logically required.

nftmapcatchallactivate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.

Compare the non-catchall activate callback, which is correct:

nftmapelemactivate(): if (nftsetelemactive(ext, iter->genmask)) return 0; / skip active, process inactive /

With the buggy catchall version:

nftmapcatchallactivate(): if (!nftsetelemactive(ext, genmask)) continue; / skip inactive, process active /

The consequence is that when a DELSET operation is aborted, nftsetelemdataactivate() is never called for the catchall element. For NFTGOTO verdict elements, this means nftdatahold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.

This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIGUSERNS and CONFIGNFTABLES.

Fix by removing the negation so the check matches nftmapelemactivate(): skip active elements, process inactive ones.

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

ipvlan: Make the addrslock be per port

Make the addrslock be per port, not per ipvlan dev.

Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So

1) Introduce per-port addrslock.

2) It was needed to fix places where it was forgotten to take lock (ipvlanopen/ipvlanclose)

This appears to be a very minor problem though. Since it's highly unlikely that ipvlanaddaddr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:

1) False-negative of ipvlanaddrbusy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlanaddr6event() can be called without rtnllock.

2) Race since ipvlanhtaddradd(port) is called under different ipvlan->addrslock locks

This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.

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

mm/hugetlb: fix hugetlbpmdshared()

Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmugather)", v3.

One functional fix, one performance regression fix, and two related comment fixes.

I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things.

The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4.

Patch #1 fixes hugetlbpmdshared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit().

The last patch is all about TLB flushes, IPIs and mmugather. Read: complicated

There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series.

Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86.

This patch (of 4):

We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->ptsharecount to identify sharing.

We didn't convert hugetlbpmdshared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table.

Page migration, like mbind() or migratepages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PMMMAPEXCLUSIVE in the pagemap interface.

Fix it by properly using ptdescpmdisshared() in hugetlbpmdshared().

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

gue: Fix skb memleak with inner IP protocol 0.

syzbot reported skb memleak below. [0]

The repro generated a GUE packet with its inner protocol 0.

gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.

Let's drop such packets.

Note that 0 is a valid number (IPv6 Hop-by-Hop Option).

I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:

no error resubmit HOPOPT

[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

scsi: xen: scsiback: Fix potential memory leak in scsibackremove()

Memory allocated for struct vscsiblkinfo in scsibackprobe() is not freed in scsibackremove() leading to potential memory leaks on remove, as well as in the scsibackprobe() error paths. Fix that by freeing it in scsibackremove().

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

vsock/virtio: cap TX credit to local buffer size

The virtio transports derives its TX credit directly from peerbufalloc, which is set from the remote endpoint's SOVMSOCKETSBUFFERSIZE value.

On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of skbuff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.

Introduce a small helper, virtiotransporttxbufsize(), that returns min(peerbufalloc, bufalloc), and use it wherever we consume peerbufalloc.

This ensures the effective TX window is bounded by both the peer's advertised buffer and our own bufalloc (already clamped to buffermaxsize via SOVMSOCKETSBUFFERMAXSIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.

On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.

With this patch applied:

Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB

After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB

Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.

Compatibility with non-virtio transports:

- VMCI uses the AFVSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer values; the remote side cannot enlarge those queues beyond what the local endpoint configured.

- Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peerbufalloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.

- The loopback path reuses virtiotransportcommon.c, so it naturally follows the same semantics as the virtio transport.

This change is limited to virtiotransportcommon.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.

[Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]

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

be2net: Fix NULL pointer dereference in becmdgetmacfromlist

When the parameter pmacidvalid argument of becmdgetmacfromlist() is set to false, the driver may request the PMACID from the firmware of the network card, and this function will store that PMACID at the provided address pmacid. This is the contract of this function.

However, there is a location within the driver where both pmacidvalid == false and pmacid == NULL are being passed. This could result in dereferencing a NULL pointer.

To resolve this issue, it is necessary to pass the address of a stub variable to the function.

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.