CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49288 – ALSA: pcm: Fix races among concurrent prealloc proc writes
https://notcve.org/view.php?id=CVE-2022-49288
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent prealloc proc writes We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations). • https://git.kernel.org/stable/c/e7786c445bb67a9a6e64f66ebd6b7215b153ff7d •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-49286 – tpm: use try_get_ops() in tpm-space.c
https://notcve.org/view.php?id=CVE-2022-49286
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: tpm: use try_get_ops() in tpm-space.c As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window... • https://git.kernel.org/stable/c/5b1d2561a03e534064b51c50c774657833d3d2cf •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2022-49281 – cifs: fix handlecache and multiuser
https://notcve.org/view.php?id=CVE-2022-49281
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: cifs: fix handlecache and multiuser In multiuser each individual user has their own tcon structure for the share and thus their own handle for a cached directory. When we umount such a share we much make sure to release the pinned down dentry for each such tcon and not just the master tcon. Otherwise we will get nasty warnings on umount that dentries are still in use: [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still i... • https://git.kernel.org/stable/c/2fafbc198613823943c106d1ec9b516da692059f •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49280 – NFSD: prevent underflow in nfssvc_decode_writeargs()
https://notcve.org/view.php?id=CVE-2022-49280
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue. • https://git.kernel.org/stable/c/1a33e0de60feda402d05ac8a6cf409c19ea3e0b3 •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2022-49279 – NFSD: prevent integer overflow on 32 bit systems
https://notcve.org/view.php?id=CVE-2022-49279
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent integer overflow on 32 bit systems On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow. • https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49277 – jffs2: fix memory leak in jffs2_do_mount_fs
https://notcve.org/view.php?id=CVE-2022-49277
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_mount_fs If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) 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 ... • https://git.kernel.org/stable/c/e631ddba588783edd521c5a89f7b2902772fb691 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49276 – jffs2: fix memory leak in jffs2_scan_medium
https://notcve.org/view.php?id=CVE-2022-49276
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_scan_medium If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 0... • https://git.kernel.org/stable/c/e631ddba588783edd521c5a89f7b2902772fb691 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2022-49271 – cifs: prevent bad output lengths in smb2_ioctl_query_info()
https://notcve.org/view.php?id=CVE-2022-49271
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: cifs: prevent bad output lengths in smb2_ioctl_query_info() When calling smb2_ioctl_query_info() with smb_query_info::flags=PASSTHRU_FSCTL and smb_query_info::output_buffer_length=0, the following would return 0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); } rather than a valid pointer thus making IS_ERR() check fail. This would then cause a... • https://git.kernel.org/stable/c/9963ccea6087268e1275b992dca5d0dd4b938765 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2022-49267 – mmc: core: use sysfs_emit() instead of sprintf()
https://notcve.org/view.php?id=CVE-2022-49267
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: mmc: core: use sysfs_emit() instead of sprintf() sprintf() (still used in the MMC core for the sysfs output) is vulnerable to the buffer overflow. Use the new-fangled sysfs_emit() instead. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. • https://git.kernel.org/stable/c/659ca56b5415c7a1d05e185c36fad80ba165d063 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49264 – exec: Force single empty string when argv is empty
https://notcve.org/view.php?id=CVE-2022-49264
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of... • https://git.kernel.org/stable/c/41f6ea5b9aaa28b740d47ffe995a5013211fdbb0 •