CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49339 – net: ipv6: unexport __init-annotated seg6_hmac_init()
https://notcve.org/view.php?id=CVE-2022-49339
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. ... • https://git.kernel.org/stable/c/bf355b8d2c30a289232042cacc1cfaea4923936c •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2022-49338 – net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules
https://notcve.org/view.php?id=CVE-2022-49338
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules CT cleanup assumes that all tc rules were deleted first, and so is free to delete the CT shared resources (e.g the dr_action fwd_action which is shared for all tuples). But currently for uplink, this is happens in reverse, causing the below trace. CT cleanup is called from: mlx5e_cleanup_rep_tx()->mlx5e_cleanup_uplink_rep_tx()-> mlx5e_rep_tc_cleanup()->mlx5e_tc_esw_cleanup()-> m... • https://git.kernel.org/stable/c/d1a3138f7913014e0714cb1d3d44793d76fc38a1 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49337 – ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
https://notcve.org/view.php?id=CVE-2022-49337
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when ba... • https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-49336 – drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem
https://notcve.org/view.php?id=CVE-2022-49336
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures. • https://git.kernel.org/stable/c/19323b3671a85788569d15685c8f83a05ec48cbb •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49335 – drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.
https://notcve.org/view.php?id=CVE-2022-49335
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a... • https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2022-49334 – mm/huge_memory: Fix xarray node memory leak
https://notcve.org/view.php?id=CVE-2022-49334
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: Fix xarray node memory leak If xas_split_alloc() fails to allocate the necessary nodes to complete the xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem() then interprets as "Please allocate more memory", not as "Please free any unnecessary memory" (which was the intended outcome). It's confusing to use xas_nomem() to free memory in this context, so call xas_destroy() instead. • https://git.kernel.org/stable/c/6b24ca4a1a8d4ee3221d6d44ddbb99f542e4bda3 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2022-49333 – net/mlx5: E-Switch, pair only capable devices
https://notcve.org/view.php?id=CVE-2022-49333
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, pair only capable devices OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities. This fixes an issue where mlx5_get_next_phys_dev() was called without holding the interface lock. This issue was found when commit bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices") added an assert that verifies the interface lock is held. WARNING: CPU: 9 PID: 1706 at drivers/n... • https://git.kernel.org/stable/c/dd3fddb82780bfa24124834edd90bbc63bd689cc •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2022-49332 – scsi: lpfc: Address NULL pointer dereference after starget_to_rport()
https://notcve.org/view.php?id=CVE-2022-49332
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Address NULL pointer dereference after starget_to_rport() Calls to starget_to_rport() may return NULL. Add check for NULL rport before dereference. • https://git.kernel.org/stable/c/bb21fc9911eea92afd476f7e64b327716e042a25 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49331 – nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
https://notcve.org/view.php?id=CVE-2022-49331
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths. • https://git.kernel.org/stable/c/26fc6c7f02cb26c39c4733de3dbc3c0646fc1074 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49330 – tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
https://notcve.org/view.php?id=CVE-2022-49330
26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot got a new report [1] finally pointing to a very old bug, added in initial support for MTU probing. tcp_mtu_probe() has checks about starting an MTU probe if tcp_snd_cwnd(tp) >= 11. But nothing prevents tcp_snd_cwnd(tp) to be reduced later and before the MTU probe succeeds. This bug would lead to potential zero-divides. Debugging added in commit 40570375356c ("tcp: add accessors to rea... • https://git.kernel.org/stable/c/5d424d5a674f782d0659a3b66d951f412901faee •