CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47659 – drm/plane: Move range check for format_count earlier
https://notcve.org/view.php?id=CVE-2021-47659
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. • https://git.kernel.org/stable/c/4ab7e453a3ee88c274cf97bee9487ab92a66d313 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49298 – staging: rtl8712: fix uninit-value in r871xu_drv_init()
https://notcve.org/view.php?id=CVE-2022-49298
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_pr... • https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49297 – nbd: fix io hung while disconnecting device
https://notcve.org/view.php?id=CVE-2022-49297
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: nbd: fix io hung while disconnecting device In our tests, "qemu-nbd" triggers a io hung: INFO: task qemu-nbd:11445 blocked for more than 368 seconds. Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000 Call Trace:
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-49296 – ceph: fix possible deadlock when holding Fwb to get inline_data
https://notcve.org/view.php?id=CVE-2022-49296
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ceph: fix possible deadlock when holding Fwb to get inline_data 1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ...... • https://git.kernel.org/stable/c/9030aaf9bf0a1eee47a154c316c789e959638b0f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49295 – nbd: call genl_unregister_family() first in nbd_cleanup()
https://notcve.org/view.php?id=CVE-2022-49295
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creat... • https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49294 – drm/amd/display: Check if modulo is 0 before dividing.
https://notcve.org/view.php?id=CVE-2022-49294
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check if modulo is 0 before dividing. [How & Why] If a value of 0 is read, then this will cause a divide-by-0 panic. • https://git.kernel.org/stable/c/10ef82d6e0af5536ec64770c07f6bbabfdd6977c •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2021-47658 – drm/amd/pm: fix a potential gpu_metrics_table memory leak
https://notcve.org/view.php?id=CVE-2021-47658
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a potential gpu_metrics_table memory leak Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(), but not freed in int smu_v12_0_fini_smc_tables(). Free it! • https://git.kernel.org/stable/c/95868b85764aff2dcbf78d3054076df75446ad15 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49293 – netfilter: nf_tables: initialize registers in nft_do_chain()
https://notcve.org/view.php?id=CVE-2022-49293
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: initialize registers in nft_do_chain() Initialize registers to avoid stack leak into userspace. • https://git.kernel.org/stable/c/96518518cc417bb0a8c80b9fb736202e28acdf96 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-49292 – ALSA: oss: Fix PCM OSS buffer allocation overflow
https://notcve.org/view.php?id=CVE-2022-49292
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: oss: Fix PCM OSS buffer allocation overflow We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params 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 give... • https://git.kernel.org/stable/c/a63af1baf0a5e11827db60e3127f87e437cab6e5 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49291 – ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
https://notcve.org/view.php?id=CVE-2022-49291
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent hw_params and hw_free calls Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params... • https://git.kernel.org/stable/c/a42aa926843acca96c0dfbde2e835b8137f2f092 •