CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2022-49051 – net: usb: aqc111: Fix out-of-bounds accesses in RX fixup
https://notcve.org/view.php?id=CVE-2022-49051
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Fix out-of-bounds accesses in RX fixup aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used ... • https://git.kernel.org/stable/c/404998a137bcb8a926f7c949030afbe285472593 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2022-49050 – memory: renesas-rpc-if: fix platform-device leak in error path
https://notcve.org/view.php?id=CVE-2022-49050
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix platform-device leak in error path Make sure to free the flash platform device in the event that registration fails during probe. • https://git.kernel.org/stable/c/ca7d8b980b67f133317525c4273e144116ee1ae5 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2022-49049 – mm/secretmem: fix panic when growing a memfd_secret
https://notcve.org/view.php?id=CVE-2022-49049
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into s... • https://git.kernel.org/stable/c/b6d17c67885a5624e96eb30c4178c65eea8374bf •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2022-49048 – ipv6: fix panic when forwarding a pkt with no in6 dev
https://notcve.org/view.php?id=CVE-2022-49048
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ipv6: fix panic when forwarding a pkt with no in6 dev kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated. The following tc commands were used to reproduce this panic: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5% • https://git.kernel.org/stable/c/bff0854e2f804f68d3e93d19e4580dbd69777e1d •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49046 – i2c: dev: check return value when calling dev_set_name()
https://notcve.org/view.php?id=CVE-2022-49046
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. • https://git.kernel.org/stable/c/1413ef638abae4ab5621901cf4d8ef08a4a48ba6 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49045 – ALSA: pcm: Test for "silence" field in struct "pcm_format_data"
https://notcve.org/view.php?id=CVE-2022-49045
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Test for "silence" field in struct "pcm_format_data" Syzbot reports "KASAN: null-ptr-deref Write in snd_pcm_format_set_silence".[1] It is due to missing validation of the "silence" field of struct "pcm_format_data" in "pcm_formats" array. Add a test for valid "pat" and, if it is not so, return -EINVAL. [1] https://lore.kernel.org/lkml/000000000000d188ef05dc2c7279@google.com/ • https://git.kernel.org/stable/c/77af45df08768401602472f3e3879dce14f55497 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-49044 – dm integrity: fix memory corruption when tag_size is less than digest size
https://notcve.org/view.php?id=CVE-2022-49044
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_... • https://git.kernel.org/stable/c/6a95d91c0b315c965198f6ab7dec7c94129e17e0 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2021-47656 – jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
https://notcve.org/view.php?id=CVE-2021-47656
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ==... • https://git.kernel.org/stable/c/aa98d7cf59b5b0764d3502662053489585faf2fe •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2021-47654 – samples/landlock: Fix path_list memory leak
https://notcve.org/view.php?id=CVE-2021-47654
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: samples/landlock: Fix path_list memory leak Clang static analysis reports this error sandboxer.c:134:8: warning: Potential leak of memory pointed to by 'path_list' ret = 0; ^ path_list is allocated in parse_path() but never freed. • https://git.kernel.org/stable/c/20fbf100f84b9aeb9c91421abe1927bc152bc32b •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2021-47653 – media: davinci: vpif: fix use-after-free on driver unbind
https://notcve.org/view.php?id=CVE-2021-47653
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: media: davinci: vpif: fix use-after-free on driver unbind The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind. This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns. Fix this by adding the missing deregistration calls to the remove() callback and failing... • https://git.kernel.org/stable/c/479f7a1181058689435baddc16a6a42e1a8ff0e8 •