OESA-2025-1336

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/plane: Move range check for format_count earlier

While the check for formatcount > 64 in _drmuniversalplaneinit() shouldn't be hit (it's a WARNON), in its current position it will then leak the plane->formattypes array and fail to call drmmodeobjectunregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.(CVE-2021-47659)

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

scsi: target: tcmu: Fix possible page UAF

tcmutrygetdatapage() looks up pages under cmdrlock, but it does not take refcount properly and just returns page pointer. When tcmutrygetdatapage() returns, the returned page may have been freed by tcmublocks_release().

We need to getpage() under cmdrlock to avoid concurrent tcmublocksrelease().(CVE-2022-49053)

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

ASoC: atmel: Add missing ofnodeput() in at91sam9g20ekaudioprobe

This node pointer is returned by ofparsephandle() with refcount incremented in this function. Calling ofnodeput() to avoid the refcount leak.(CVE-2022-49243)

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

ALSA: oss: Fix PCM OSS buffer allocation overflow

We've got syzbot reports hitting INTMAX overflow at vmalloc() allocation that is called from sndpcmplugalloc(). Although we apply the restrictions to input parameters, it's based only on the hwparams of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INTMAX, hence it hits WARN_ON().

This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated.

In addition, the driver uses arraysize() and array3size() for multiplications to catch overflows for the converted period size and buffer bytes.(CVE-2022-49292)

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

drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.

Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver.

MESALOADERDRIVER_OVERRIDE=v3d glxinfo

[172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: errorcode(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpucsioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpucsfindmapping+0x110/0x110 [amdgpu] [172536.665332] drmioctlkernel+0xaa/0xf0 [drm] [172536.665338] drmioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpucsfindmapping+0x110/0x110 [amdgpu] [172536.665372] ? selinuxfileioctl+0x135/0x230 [172536.665399] amdgpudrmioctl+0x49/0x80 [amdgpu] [172536.665403] _x64sysioctl+0x83/0xb0 [172536.665406] dosyscall64+0x33/0x40 [172536.665409] entrySYSCALL64after_hwframe+0x44/0xa9

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018(CVE-2022-49335)

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

net: mdio: unexport _init-annotated mdiobus_init()

EXPORTSYMBOL and _init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds.

There are two ways to fix it:

• Remove __init
• Remove EXPORT_SYMBOL

I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phydevice.c is never compiled as modular. (CONFIGPHYLIB is boolean)(CVE-2022-49350)

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

jffs2: fix memory leak in jffs2dofill_super

If jffs2iget() or dmakeroot() in jffs2dofillsuper() returns an error, we can observe the following kmemleak report:

unreferenced object 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff859c45e5>] kmemcachealloctrace+0x475/0x8a0 [<ffffffff86160146>] jffs2suminit+0x96/0x1a0 [<ffffffff86140e25>] jffs2domountfs+0x745/0x2120 [<ffffffff86149fec>] jffs2dofillsuper+0x35c/0x810 [<ffffffff8614aae9>] jffs2fillsuper+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffff858579ba>] kmallocorder+0xda/0x110 [<ffffffff85857a11>] kmallocordertrace+0x21/0x130 [<ffffffff859c2ed1>] _kmalloc+0x711/0x8a0 [<ffffffff86160189>] jffs2suminit+0xd9/0x1a0 [<ffffffff86140e25>] jffs2domountfs+0x745/0x2120 [<ffffffff86149fec>] jffs2dofillsuper+0x35c/0x810 [<ffffffff8614aae9>] jffs2fill_super+0x2b9/0x3b0

[...]

This is because the resources allocated in jffs2suminit() are not released. Call jffs2sumexit() to release these resources to solve the problem.(CVE-2022-49381)

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

ubi: ubicreatevolume: Fix use-after-free when volume creation failed

There is an use-after-free problem for 'ebatbl' in ubicreate_volume()'s error handling path:

ubiebareplacetable(vol, ebatbl) vol->ebatbl = tbl outmapping: ubiebadestroytable(ebatbl) // Free 'ebatbl' outunlock: putdevice(&vol->dev) volrelease kfree(tbl->entries) // UAF

Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].(CVE-2022-49388)

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

drm/msm/mdp5: Return error code in mdp5piperelease when deadlock is detected

mdp5getglobalstate runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5piperelease doesn't check for if an error is returned. Because of this, there is a possibility of mdp5pipe_release hitting a NULL dereference error.

To avoid this, let's have mdp5piperelease check if mdp5getglobal_state returns an error and propogate that error.

Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message

Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5mixerrelease

Patchwork: https://patchwork.freedesktop.org/patch/485179/(CVE-2022-49490)

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

HID: elan: Fix potential double free in elaninputconfigured

'input' is a managed resource allocated with devminputallocatedevice(), so there is no need to call inputfree_device() explicitly or there will be a double free.

According to the doc of devminputallocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).(CVE-2022-49508)

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

scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI

If lpfcissueels_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference.

Similarly, when processing non-zero ELS PLOGI completion status in lpfccmplelsplogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfcdevlosstmo_handler() results in a use after free ndlp dereference.

Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling.(CVE-2022-49535)

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

ip: Fix data-races around sysctlipfwdupdatepriority.

While reading sysctlipfwdupdatepriority, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.(CVE-2022-49603)

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

sfc: fix kernel panic when creating VF

When creating VFs a kernel panic can happen when calling to efxef10tryupdatenicstatsvf.

When releasing a DMA coherent buffer, sometimes, I don't know in what specific circumstances, it has to unmap memory with vunmap. It is disallowed to do that in IRQ context or with BH disabled. Otherwise, we hit this line in vunmap, causing the crash: BUGON(ininterrupt());

This patch reenables BH to release the buffer.

Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x8664 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: _iommudmafree+0x96/0x100 efxnicfreebuffer+0x2b/0x40 [sfc] efxef10tryupdatenicstatsvf+0x14a/0x1c0 [sfc] efxef10updatestatsvf+0x18/0x40 [sfc] efxstartall+0x15e/0x1d0 [sfc] efxnetopen+0x5a/0xe0 [sfc] _devopen+0xe7/0x1a0 _devchangeflags+0x1d7/0x240 devchangeflags+0x21/0x60 ...skip...(CVE-2022-49625)

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

soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstbpmprobe

offindmatchingnode() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnode_put() to avoid refcount leak.

In brcmstbinitsram, it pass dn to ofaddresstoresource(), ofaddresstoresource() will call offinddevicebynode() to take reference, so we should release the reference returned by offindmatching_node().(CVE-2022-49678)

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

usb: dwc2: Fix memory leak in dwc2hcdinit

usbcreatehcd will alloc memory for hcd, and we should call usbputhcd to free it when platformgetresource() fails to prevent memory leak. goto error2 label instead error1 to fix this.(CVE-2022-49713)

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

block: Fix handling of offline queues in blkmqallocrequesthctx()

This patch prevents that test nvme/004 triggers the following:

UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9 index 512 is out of range for type 'long unsigned int [512]' Call Trace: showstack+0x52/0x58 dumpstacklvl+0x49/0x5e dumpstack+0x10/0x12 ubsanepilogue+0x9/0x3b _ubsanhandleoutofbounds.cold+0x44/0x49 blkmqallocrequesthctx+0x304/0x310 _nvmesubmitsynccmd+0x70/0x200 [nvmecore] nvmfconnectioqueue+0x23e/0x2a0 [nvmefabrics] nvmeloopconnectioqueues+0x8d/0xb0 [nvmeloop] nvmeloopcreatectrl+0x58e/0x7d0 [nvmeloop] nvmfcreatectrl+0x1d7/0x4d0 [nvmefabrics] nvmfdevwrite+0xae/0x111 [nvmefabrics] vfswrite+0x144/0x560 ksyswrite+0xb7/0x140 _x64syswrite+0x42/0x50 dosyscall64+0x35/0x80 entrySYSCALL64after_hwframe+0x44/0xae(CVE-2022-49720)

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

ipv6: Fix signed integer overflow in l2tpip6sendmsg

When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.(CVE-2022-49727)

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

vfio/platform: check the bounds of read/write syscalls

count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)

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

net: let net.core.dev_weight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? _warn+0xcd/0x250 ? _listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 _netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 _devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 _syssendto+0x3bf/0x4e0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until _dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueueto_backlog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).(CVE-2025-21806)