CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49100 – virtio_console: eliminate anonymous module_init & module_exit
https://notcve.org/view.php?id=CVE-2022-49100
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (init... • https://git.kernel.org/stable/c/93e3d88321d2274fa4e26b006e19cc10fec331c2 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49097 – NFS: Avoid writeback threads getting stuck in mempool_alloc()
https://notcve.org/view.php?id=CVE-2022-49097
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: NFS: Avoid writeback threads getting stuck in mempool_alloc() In a low memory situation, allow the NFS writeback code to fail without getting stuck in infinite loops in mempool_alloc(). • https://git.kernel.org/stable/c/c74e2f6ecc51bd08bb5b0335477dba954a50592e •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49095 – scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()
https://notcve.org/view.php?id=CVE-2022-49095
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function. • https://git.kernel.org/stable/c/45804fbb00eea27bdf4d62751681228a9e2844e9 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-49086 – net: openvswitch: fix leak of nested actions
https://notcve.org/view.php?id=CVE-2022-49086
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the ... • https://git.kernel.org/stable/c/34ae932a40369be6bd6ea97d66b6686361b4370d •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49080 – mm/mempolicy: fix mpol_new leak in shared_policy_replace
https://notcve.org/view.php?id=CVE-2022-49080
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could ... • https://git.kernel.org/stable/c/42288fe366c4f1ce7522bc9f27d0bc2a81c55264 •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2022-49078 – lz4: fix LZ4_decompress_safe_partial read out of bound
https://notcve.org/view.php?id=CVE-2022-49078
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been dis... • https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49077 – mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)
https://notcve.org/view.php?id=CVE-2022-49077
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of ... • https://git.kernel.org/stable/c/a05540f3903bd8295e8c4cd90dd3d416239a115b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49075 – btrfs: fix qgroup reserve overflow the qgroup limit
https://notcve.org/view.php?id=CVE-2022-49075
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changese... • https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-49074 – irqchip/gic-v3: Fix GICR_CTLR.RWP polling
https://notcve.org/view.php?id=CVE-2022-49074
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. • https://git.kernel.org/stable/c/021f653791ad17e03f98aaa7fb933816ae16f161 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49072 – gpio: Restrict usage of GPIO chip irq members before initialization
https://notcve.org/view.php?id=CVE-2022-49072
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: gpio: Restrict usage of GPIO chip irq members before initialization GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for re... • https://git.kernel.org/stable/c/7e88a50704b0c49ad3f2d11e8b963341cf68a89f •