OESA-2025-1569

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

gfs2: Check sbbsizeshift after reading superblock

Fuzzers like to scribble over sbbsizeshift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value.

Tested with:

mkfs.gfs2 -O -p lock_nolock /dev/vdb
for i in 0 -1 64 65 32 33; do
    gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
    mount /dev/vdb /mnt/test && umount /mnt/test
done

Before this patch we get a withdraw after

[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2metabuffer, file = fs/gfs2/meta_io.c, line = 492

and with UBSAN configured we also get complaints like

[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'

After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg.(CVE-2022-49769)

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

misc/vmwvmci: fix an infoleak in vmcihostdoreceive_datagram()

struct vmci_event_qp allocated by qpnotifypeer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN:

BUG: KMSAN: kernel-infoleak in instrumentcopytouser ./include/linux/instrumented.h:121 instrumentcopytouser ./include/linux/instrumented.h:121 copytouser+0x5f/0xb0 lib/usercopy.c:33 copytouser ./include/linux/uaccess.h:169 vmcihostdoreceivedatagram drivers/misc/vmwvmci/vmcihost.c:431 vmcihostunlockedioctl+0x33d/0x43d0 drivers/misc/vmwvmci/vmcihost.c:925 vfs_ioctl fs/ioctl.c:51 ...

Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dgdispatchashost drivers/misc/vmwvmci/vmcidatagram.c:271 vmcidatagramdispatch+0x4f8/0xfc0 drivers/misc/vmwvmci/vmcidatagram.c:339 qpnotifypeer+0x19a/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1479 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750 vmciqpbrokeralloc+0x96/0xd0 drivers/misc/vmwvmci/vmciqueuepair.c:1940 vmcihostdoallocqueuepair drivers/misc/vmwvmci/vmcihost.c:488 vmcihostunlockedioctl+0x24fd/0x43d0 drivers/misc/vmwvmci/vmci_host.c:927 ...

Local variable ev created at: qpnotifypeer+0x54/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1456 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueue_pair.c:1750

Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100

Use memset() to prevent the infoleaks.

Also speculatively fix qpnotifypeer_local(), which may suffer from the same problem.(CVE-2022-49788)

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

HID: hyperv: fix possible memory leak in mousevsc_probe()

If hidadddevice() returns error, it should call hiddestroydevice() to free hiddev which is allocated in hidallocate_device().(CVE-2022-49874)

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

netsched: schsfq: move the limit validation

It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.

Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:

tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1

This fixes the following syzkaller reported crash:

------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/schsfq.c:203:6 index 65535 is out of range for type 'struct sfqhead[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleoutofbounds+0xf5/0x120 lib/ubsan.c:429 sfqlink net/sched/schsfq.c:203 [inline] sfqdec+0x53c/0x610 net/sched/schsfq.c:231 sfqdequeue+0x34e/0x8c0 net/sched/schsfq.c:493 sfqreset+0x17/0x60 net/sched/schsfq.c:518 qdiscreset+0x12e/0x600 net/sched/schgeneric.c:1035 tbfreset+0x41/0x110 net/sched/schtbf.c:339 qdiscreset+0x12e/0x600 net/sched/schgeneric.c:1035 devresetqueue+0x100/0x1b0 net/sched/schgeneric.c:1311 netdevforeachtxqueue include/linux/netdevice.h:2590 [inline] devdeactivatemany+0x7e5/0xe70 net/sched/schgeneric.c:1375(CVE-2025-37752)

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

dm-bufio: don't schedule in atomic context

A BUG was reported as below when CONFIGDEBUGATOMICSLEEP and tryverifyintasklet are enabled. [ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preemptcount: 201, expected: 0 [ 129.444756][ T934] RCU nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [ 129.444789][ T934] [<ffffffd816231900>] shrinkwork+0x21c/0x248 [ 129.445167][ T934] kernel BUG at kernel/sched/walt/waltdebug.c:16! [ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Workqueue: dmbufiocache shrinkwork [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : androidrvhschedulebug+0x0/0x8 [schedwaltdebug] [ 129.447435][ T934] lr : _traceiterandroidrvhschedulebug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Call trace: [ 129.447655][ T934] androidrvhschedulebug+0x0/0x8 [schedwaltdebug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] _mightresched+0x190/0x1a8 [ 129.447694][ T934] shrinkwork+0x180/0x248 [ 129.447706][ T934] processonework+0x260/0x624 [ 129.447718][ T934] workerthread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [ 129.447742][ T934] retfromfork+0x10/0x20 [ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace 0000000000000000 ]---

dmbufiolock will call spinlockbh when tryverifyintasklet is enabled, and _scan will be called in atomic context.(CVE-2025-37928)

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

block: fix resource leak in blkregisterqueue() error path

When registering a queue fails after blkmqsysfsregister() is successful but the function later encounters an error, we need to clean up the blkmq_sysfs resources.

Add the missing blkmqsysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.(CVE-2025-37980)