huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49911: kernel: netfilter: ipset: enforce documented limit to prevent allocating huge memory
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: enforce documented limit to prevent allocating huge memory

Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.

The quick reproducer is

$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done

The backtrace when vmalloc fails:

        [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
        <...>
        [Tue Oct 25 00:13:08 2022] Call Trace:
        [Tue Oct 25 00:13:08 2022]  <TASK>
        [Tue Oct 25 00:13:08 2022]  dump_stack_lvl+0x48/0x60
        [Tue Oct 25 00:13:08 2022]  warn_alloc+0x155/0x180
        [Tue Oct 25 00:13:08 2022]  __vmalloc_node_range+0x72a/0x760
        [Tue Oct 25 00:13:08 2022]  ? hash_netiface4_add+0x7c0/0xb20
        [Tue Oct 25 00:13:08 2022]  ? __kmalloc_large_node+0x4a/0x90
        [Tue Oct 25 00:13:08 2022]  kvmalloc_node+0xa6/0xd0
        [Tue Oct 25 00:13:08 2022]  ? hash_netiface4_resize+0x99/0x710
        <...>

The fix is to enforce the limit documented in the ipset(8) manpage:

>  The internal restriction of the hash:net,iface set type is that the same
>  network prefix cannot be stored with more than 64 different interfaces
>  in a single set.


Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.78, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 42d20d5e24575c9afa2d66d9a51e7386db9514f5
CVE-2022-49920: kernel: netfilter: nf_tables: netlink notifier might race to release objects
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: netlink notifier might race to release objects

commit release path is invoked via call_rcu and it runs lockless to
release the objects after rcu grace period. The netlink notifier handler
might win race to remove objects that the transaction context is still
referencing from the commit release path.

Call rcu_barrier() to ensure pending rcu callbacks run to completion
if the list of transactions to be destroyed is not empty.

Statement: The bug could happen only when qdisc with child qdiscs like netem or codel being used.

Affected upstream versions: 5.12
Fixed upstream versions: 0, 5.15.78, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1ffe7100411a8b9015115ce124cd6c9c9da6f8e3
CVE-2022-49925: kernel: RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Fix null-ptr-deref in ib_core_cleanup()

KASAN reported a null-ptr-deref error:

  KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
  CPU: 1 PID: 379
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  RIP: 0010:destroy_workqueue+0x2f/0x740
  RSP: 0018:ffff888016137df8 EFLAGS: 00000202
  ...
  Call Trace:
   ib_core_cleanup+0xa/0xa1 [ib_core]
   __do_sys_delete_module.constprop.0+0x34f/0x5b0
   do_syscall_64+0x3a/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
  RIP: 0033:0x7fa1a0d221b7
  ...

It is because the fail of roce_gid_mgmt_init() is ignored:

 ib_core_init()
   roce_gid_mgmt_init()
     gid_cache_wq = alloc_ordered_workqueue # fail
 ...
 ib_core_cleanup()
   roce_gid_mgmt_cleanup()
     destroy_workqueue(gid_cache_wq)
     # destroy an unallocated wq

Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().


Affected upstream versions: 4.3
Fixed upstream versions: 0, 5.10.154, 5.15.78, 5.4.224, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: af8fb5a0600e9ae29950e9422a032c3c22649ee5
CVE-2022-49934: kernel: wifi: mac80211: Fix UAF in ieee80211_scan_rx()
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Fix UAF in ieee80211_scan_rx()

ieee80211_scan_rx() tries to access scan_req->flags after a
null check, but a UAF is observed when the scan is completed
and __ieee80211_scan_completed() executes, which then calls
cfg80211_scan_done() leading to the freeing of scan_req.

Since scan_req is rcu_dereference()'d, prevent the racing in
__ieee80211_scan_completed() by ensuring that from mac80211's
POV it is no longer accessed from an RCU read critical section
before we call cfg80211_scan_done().


Affected upstream versions: 3.19
Fixed upstream versions: 0, 4.14.295, 4.19.260, 4.9.330, 5.10.142, 5.15.66, 5.19.8, 5.4.215, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6eb181a64fdabf10be9e54de728876667da20255
CVE-2022-49935: kernel: dma-buf/dma-resv: check if the new fence is really later
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dma-buf/dma-resv: check if the new fence is really later

Previously when we added a fence to a dma_resv object we always
assumed the the newer than all the existing fences.

With Jason's work to add an UAPI to explicit export/import that's not
necessary the case any more. So without this check we would allow
userspace to force the kernel into an use after free error.

Since the change is very small and defensive it's probably a good
idea to backport this to stable kernels as well just in case others
are using the dma_resv object in the same way.


Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c4c798fe98adceb642050819cb57cbc8f5c27870
CVE-2022-49940: kernel: tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()

A null pointer dereference can happen when attempting to access the
"gsm->receive()" function in gsmld_receive_buf(). Currently, the code
assumes that gsm->recieve is only called after MUX activation.
Since the gsmld_receive_buf() function can be accessed without the need to
initialize the MUX, the gsm->receive() function will not be set and a
NULL pointer dereference will occur.

Fix this by avoiding the call to "gsm->receive()" in case the function is
not initialized by adding a sanity check.

Call Trace:
 <TASK>
 gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861
 tiocsti drivers/tty/tty_io.c:2293 [inline]
 tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd


Affected upstream versions: 5.18.18 < 5.19, 5.15.61 < 5.15.66, 5.19.2 < 5.19.8
Fixed upstream versions: 5.15.66, 5.19, 5.19.8
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5a82cf64f8ad63caf6bf115642ce44ddbc64311e
CVE-2022-49942: kernel: wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected

When we are not connected to a channel, sending channel "switch"
announcement doesn't make any sense.

The BSS list is empty in that case. This causes the for loop in
cfg80211_get_bss() to be bypassed, so the function returns NULL
(check line 1424 of net/wireless/scan.c), causing the WARN_ON()
in ieee80211_ibss_csa_beacon() to get triggered (check line 500
of net/mac80211/ibss.c), which was consequently reported on the
syzkaller dashboard.

Thus, check if we have an existing connection before generating
the CSA beacon in ieee80211_ibss_finish_csa().


Affected upstream versions: 3.13
Fixed upstream versions: 0, 4.14.293, 4.19.258, 4.9.328, 5.10.142, 5.15.66, 5.19.8, 5.4.213, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cdb9a8da9b84800eb15506cd9363cf0cf059e677
CVE-2022-49944: kernel: Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()"
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()"

The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common
function ucsi_unregister_connectors()") introduced a regression that
caused NULL dereference at reading the power supply sysfs.  It's a
stale sysfs entry that should have been removed but remains with NULL
ops.  The commit changed the error handling to skip the entries after
a NULL con->wq, and this leaves the power device unreleased.

For addressing the regression, the straight revert is applied here.
Further code improvements can be done from the scratch again.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3d4044c9e6d2e3f11f1f8b5e0ee8647d3eb1afad
CVE-2022-49951: kernel: firmware_loader: Fix use-after-free during unregister
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Fix use-after-free during unregister

In the following code within firmware_upload_unregister(), the call to
device_unregister() could result in the dev_release function freeing the
fw_upload_priv structure before it is dereferenced for the call to
module_put(). This bug was found by the kernel test robot using
CONFIG_KASAN while running the firmware selftests.

  device_unregister(&fw_sysfs->dev);
  module_put(fw_upload_priv->module);

The problem is fixed by copying fw_upload_priv->module to a local variable
for use when calling device_unregister().


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d380d40930a674c520a5b55f3be1eb17dc634ebc
CVE-2022-49958: kernel: net/sched: fix netdevice reference leaks in attach_default_qdiscs()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net/sched: fix netdevice reference leaks in attach_default_qdiscs()

In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails
to attach qdisc because there is no memory in attach_one_default_qdisc().
Then dev->qdisc will be noop_qdisc by default. But the other queues may be
able to successfully attach to default qdisc.

In this case, the fallback to noqueue process will be triggered. If the
original attached qdisc is not released and a new one is directly
attached, this will cause netdevice reference leaks.

The following is the bug log:

veth0: default qdisc (fq_codel) fail, fallback to noqueue
unregister_netdevice: waiting for veth0 to become free. Usage count = 32
leaked reference.
 qdisc_alloc+0x12e/0x210
 qdisc_create_dflt+0x62/0x140
 attach_one_default_qdisc.constprop.41+0x44/0x70
 dev_activate+0x128/0x290
 __dev_open+0x12a/0x190
 __dev_change_flags+0x1a2/0x1f0
 dev_change_flags+0x23/0x60
 do_setlink+0x332/0x1150
 __rtnl_newlink+0x52f/0x8e0
 rtnl_newlink+0x43/0x70
 rtnetlink_rcv_msg+0x140/0x3b0
 netlink_rcv_skb+0x50/0x100
 netlink_unicast+0x1bb/0x290
 netlink_sendmsg+0x37c/0x4e0
 sock_sendmsg+0x5f/0x70
 ____sys_sendmsg+0x208/0x280

Fix this bug by clearing any non-noop qdiscs that may have been assigned
before trying to re-attach.


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.142, 5.15.66, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 44dfa645895a56f65461249deb5b81cd16560e2a
CVE-2022-49959: kernel: openvswitch: fix memory leak at failed datapath creation
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the openvswitch module in the Linux kernel. A missing release of allocated memory when an error occurs will cause a memory leak, potentially impacting system performance and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.8 and 9.2 via RHSA-2023:2951 [1] and RHSA-2023:2458 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:2951

[2]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 5.15
Fixed upstream versions: 0, 5.15.66, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ca54b2bfaab385778e55a9fd33f6c31e7f743b48
CVE-2022-49960: kernel: drm/i915: fix null pointer dereference
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/i915: fix null pointer dereference

Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
The root cause is null pointer defeference of bi_next
in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.

BUG: kernel NULL pointer dereference, address: 000000000000002e
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G     U            5.17.0-rc1
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
RIP: 0010:tgl_get_bw_info+0x2de/0x510
...
[    2.554467] Call Trace:
[    2.554467]  <TASK>
[    2.554467]  intel_bw_init_hw+0x14a/0x434
[    2.554467]  ? _printk+0x59/0x73
[    2.554467]  ? _dev_err+0x77/0x91
[    2.554467]  i915_driver_hw_probe+0x329/0x33e
[    2.554467]  i915_driver_probe+0x4c8/0x638
[    2.554467]  i915_pci_probe+0xf8/0x14e
[    2.554467]  ? _raw_spin_unlock_irqrestore+0x12/0x2c
[    2.554467]  pci_device_probe+0xaa/0x142
[    2.554467]  really_probe+0x13f/0x2f4
[    2.554467]  __driver_probe_device+0x9e/0xd3
[    2.554467]  driver_probe_device+0x24/0x7c
[    2.554467]  __driver_attach+0xba/0xcf
[    2.554467]  ? driver_attach+0x1f/0x1f
[    2.554467]  bus_for_each_dev+0x8c/0xc0
[    2.554467]  bus_add_driver+0x11b/0x1f7
[    2.554467]  driver_register+0x60/0xea
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  i915_init+0x2c/0xb9
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  do_one_initcall+0x12e/0x2b3
[    2.554467]  do_initcall_level+0xd6/0xf3
[    2.554467]  do_initcalls+0x4e/0x79
[    2.554467]  kernel_init_freeable+0xed/0x14d
[    2.554467]  ? rest_init+0xc1/0xc1
[    2.554467]  kernel_init+0x1a/0x120
[    2.554467]  ret_from_fork+0x1f/0x30
[    2.554467]  </TASK>
...
Kernel panic - not syncing: Fatal exception

(cherry picked from commit c247cd03898c4c43c3bce6d4014730403bc13032)


Affected upstream versions: 5.17
Fixed upstream versions: 0, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c2798203315f4729bab0b917bf4c17a159abf9f8
CVE-2022-49962: kernel: xhci: Fix null pointer dereference in remove if xHC has only one roothub
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix null pointer dereference in remove if xHC has only one roothub

The remove path in xhci platform driver tries to remove and put both main
and shared hcds even if only a main hcd exists (one roothub)

This causes a null pointer dereference in reboot for those controllers.

Check that the shared_hcd exists before trying to remove it.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7081b2f34ff291ada012bd6abacaf7d51c4cf73f
CVE-2022-49964: kernel: arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

An integer overflow exists in the linux kernel such that the value
returned from acpi_find_last_cache_level() is then assigned to unsigned fw_level, which will result in the number of cache leaves calculated incorrectly, resulting in damage to the confidentiality, integrity, and availability of the system.


Affected upstream versions: 5.19.4 < 5.19.7
Fixed upstream versions: 5.19.7
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a754ee1c66bd0a23e613f0bf865053b29cb90e16
CVE-2022-49965: kernel: drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics

Without these, potential memory leak may be induced.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 22a75c616f1971c23838506b14971a4ef4a66bd7
CVE-2022-49966: kernel: drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid

To avoid any potential memory leak.


Affected upstream versions: 5.9
Fixed upstream versions: 0, 5.10.141, 5.15.65, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 60d522f317078381ff8a3599fe808f96fc256cd5
CVE-2022-49967: kernel: bpf: Fix a data-race around bpf_jit_limit.
Component: kernel
Severity: Moderate
CWE: CWE-367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a data-race around bpf_jit_limit.

While reading bpf_jit_limit, it can be changed concurrently via sysctl,
WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit
is long, so we need to add a paired READ_ONCE() to avoid load-tearing.


Affected upstream versions: 4.9.190 < 4.10, 4.14.140 < 4.15, 4.19.47 < 4.20, 4.20
Fixed upstream versions: 0, 4.10, 4.15, 4.20, 5.19.8, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ba632ad0bacb13197a8f38e7526448974e87f292
CVE-2022-49969: kernel: drm/amd/display: clear optc underflow before turn off odm clock
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: clear optc underflow before turn off odm clock

[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not work.
We need to clear that before clock off.

[How]
Clear that if have when clock off.


Affected upstream versions: 4.15
Fixed upstream versions: 0, 4.19.257, 5.10.141, 5.15.65, 5.19.7, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 443687798d6f094412b7312b64b3bb4d99aedff7
CVE-2022-49971: kernel: drm/amd/pm: Fix a potential gpu_metrics_table memory leak
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

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
smu_v13_0_4_init_smc_tables(), but not freed in
smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4b25bdb54578f3b96ff055e5d27bc1cb82950e51
CVE-2022-49973: kernel: skmsg: Fix wrong last sg check in sk_msg_recvmsg()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

skmsg: Fix wrong last sg check in sk_msg_recvmsg()

Fix one kernel NULL pointer dereference as below:

[  224.462334] Call Trace:
[  224.462394]  __tcp_bpf_recvmsg+0xd3/0x380
[  224.462441]  ? sock_has_perm+0x78/0xa0
[  224.462463]  tcp_bpf_recvmsg+0x12e/0x220
[  224.462494]  inet_recvmsg+0x5b/0xd0
[  224.462534]  __sys_recvfrom+0xc8/0x130
[  224.462574]  ? syscall_trace_enter+0x1df/0x2e0
[  224.462606]  ? __do_page_fault+0x2de/0x500
[  224.462635]  __x64_sys_recvfrom+0x24/0x30
[  224.462660]  do_syscall_64+0x5d/0x1d0
[  224.462709]  entry_SYSCALL_64_after_hwframe+0x65/0xca

In commit 9974d37ea75f ("skmsg: Fix invalid last sg check in
sk_msg_recvmsg()"), we change last sg check to sg_is_last(),
but in sockmap redirection case (without stream_parser/stream_verdict/
skb_verdict), we did not mark the end of the scatterlist. Check the
sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all
do not mark the end of sg. They are expected to use sg.end for end
judgment. So the judgment of '(i != msg_rx->sg.end)' is added back here.


Affected upstream versions: 5.18.18 < 5.19, 5.15.61 < 5.15.66, 5.19.2 < 5.19.8
Fixed upstream versions: 5.15.66, 5.19, 5.19.8
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: de22cba333d8699ad77e79f862fe1320cb1284de