CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2023-53275 – ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
https://notcve.org/view.php?id=CVE-2023-53275
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer derefer... • https://git.kernel.org/stable/c/109f0aaa0b8838a88af9125b79579023539300a7 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2023-53273 – Drivers: vmbus: Check for channel allocation before looking up relids
https://notcve.org/view.php?id=CVE-2023-53273
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: Drivers: vmbus: Check for channel allocation before looking up relids relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service routine is cal... • https://git.kernel.org/stable/c/8b6a877c060ed6b86878fe66c7c6493a6054cf23 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2023-53272 – net: ena: fix shift-out-of-bounds in exponential backoff
https://notcve.org/view.php?id=CVE-2023-53272
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: net: ena: fix shift-out-of-bounds in exponential backoff The ENA adapters on our instances occasionally reset. Once recently logged a UBSAN failure to console in the process: UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BI... • https://git.kernel.org/stable/c/4bb7f4cf60e38a00965d22aa5979ab143193d41f •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2023-53271 – ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
https://notcve.org/view.php?id=CVE-2023-53271
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() There is a memory leaks problem reported by kmemleak: unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2023-53270 – ext4: fix i_disksize exceeding i_size problem in paritally written case
https://notcve.org/view.php?id=CVE-2023-53270
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_disksize exceeding i_size problem in paritally written case It is possible for i_disksize can exceed i_size, triggering a warning. generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | ... • https://git.kernel.org/stable/c/64769240bd07f446f83660bb143bb609d8ab4910 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2023-53268 – ASoC: fsl_mqs: move of_node_put() to the correct location
https://notcve.org/view.php?id=CVE-2023-53268
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns. • https://git.kernel.org/stable/c/a9d273671440c439c4f236123c59dd839c1a0eb7 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2023-53265 – ubi: ensure that VID header offset + VID header size <= alloc, size
https://notcve.org/view.php?id=CVE-2023-53265
16 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset + VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task ... • https://git.kernel.org/stable/c/801c135ce73d5df1caf3eca35b66a10824ae0707 •
CVSS: 6.3EPSS: %CPEs: 1EXPL: 0CVE-2022-50338 – binder: fix UAF of alloc->vma in race with munmap()
https://notcve.org/view.php?id=CVE-2022-50338
15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of alloc->vma in race with munmap() In commit 720c24192404 ("ANDROID: binder: change down_write to down_read") binder assumed the mmap read lock is sufficient to protect alloc->vma inside binder_update_page_range(). This used to be accurate until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"), which now downgrades the mmap_lock after detaching the vma from the rbtree in munmap(). Then it proceeds to... • https://git.kernel.org/stable/c/dd2283f2605e3b3e9c61bcae844b34f2afa4813f •
CVSS: 7.1EPSS: %CPEs: 5EXPL: 0CVE-2022-50337 – ocxl: fix pci device refcount leak when calling get_function_0()
https://notcve.org/view.php?id=CVE-2022-50337
15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ocxl: fix pci device refcount leak when calling get_function_0() get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci... • https://git.kernel.org/stable/c/87db7579ebd5ded337056eb765542eb2608f16e3 •
CVSS: 7.8EPSS: %CPEs: 5EXPL: 0CVE-2022-50335 – 9p: set req refcount to zero to avoid uninitialized usage
https://notcve.org/view.php?id=CVE-2022-50335
15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff888... • https://git.kernel.org/stable/c/728356dedeff8ef999cb436c71333ef4ac51a81c •