huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49626: kernel: sfc: fix use after free when disabling sriov
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-02-26T00:00:00+00:00

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

sfc: fix use after free when disabling sriov

Use after free is detected by kfence when disabling sriov. What was read
after being freed was vf->pci_dev: it was freed from pci_disable_sriov
and later read in efx_ef10_sriov_free_vf_vports, called from
efx_ef10_sriov_free_vf_vswitching.

Set the pointer to NULL at release time to not trying to read it later.

Reproducer and dmesg log (note that kfence doesn't detect it every time):
$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs
$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs

 BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]

 Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):
  efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]
  efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xfe/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k

 allocated by task 6771 on cpu 10 at 3137.860196s:
  pci_alloc_dev+0x21/0x60
  pci_iov_add_virtfn+0x2a2/0x320
  sriov_enable+0x212/0x3e0
  efx_ef10_sriov_configure+0x67/0x80 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xba/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 freed by task 6771 on cpu 12 at 3170.991309s:
  device_release+0x34/0x90
  kobject_cleanup+0x3a/0x130
  pci_iov_remove_virtfn+0xd9/0x120
  sriov_disable+0x30/0xe0
  efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xfe/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae


Affected upstream versions: 4.2
Fixed upstream versions: 0, 4.14.289, 4.19.253, 4.9.324, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3199e34912d84cdfb8a93a984c5ae5c73fb13e84
CVE-2022-49627: kernel: ima: Fix potential memory leak in ima_init_crypto()
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-02-26T00:00:00+00:00

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

ima: Fix potential memory leak in ima_init_crypto()

On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak.


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c1d9702ceb4a091da6bee380627596d1fba09274
CVE-2022-49629: kernel: nexthop: Fix data-races around nexthop_compat_mode.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

nexthop: Fix data-races around nexthop_compat_mode.

While reading nexthop_compat_mode, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a51040d4b120f3520df64fb0b9c63b31d69bea9b
CVE-2022-49630: kernel: tcp: Fix a data-race around sysctl_tcp_ecn_fallback.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

tcp: Fix a data-race around sysctl_tcp_ecn_fallback.

While reading sysctl_tcp_ecn_fallback, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.


Affected upstream versions: 4.2
Fixed upstream versions: 0, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8bcf7339f2cf70ea4461df6ea045d1aadfabfa11
CVE-2022-49631: kernel: raw: Fix a data-race around sysctl_raw_l3mdev_accept.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

A flaw was found in the RAW-IP module in the Linux kernel. A race condition can occur when reading the sysctl_raw_l3mdev_accept resource due to a missing lock, potentially impacting system stability and resulting in a denial of service.

Statement: The RAW-IP module in the Linux kernel as shipped in Red Hat Enterprise Linux 8 is not affected by this vulnerability because the vulnerable code was introduced in a newer version of the Linux kernel.

This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

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

Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cc9540ba5b3652c473af7e54892a48cdced87983
CVE-2022-49632: kernel: icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

A flaw was found in the Linux kernel's ICMP protocol. A race condition can occur when reading the sysctl_icmp_errors_use_inbound_ifaddr resource due to a missing lock, potentially impacting system stability and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

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

Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: de9490c32bc10020efdd1509689a28f197d6dfb8
CVE-2022-49634: kernel: sysctl: Fix data-races in proc_dou8vec_minmax().
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

sysctl: Fix data-races in proc_dou8vec_minmax().

A sysctl variable is accessed concurrently, and there is always a chance
of data-race.  So, all readers and writers need some basic protection to
avoid load/store-tearing.

This patch changes proc_dou8vec_minmax() to use READ_ONCE() and
WRITE_ONCE() internally to fix data-races on the sysctl side.  For now,
proc_dou8vec_minmax() itself is tolerant to a data-race, but we still
need to add annotations on the other subsystem's side.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f177b382c33900d0e5a9766493c11a1074076f78
CVE-2022-49637: kernel: ipv4: Fix a data-race around sysctl_fib_sync_mem.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

ipv4: Fix a data-race around sysctl_fib_sync_mem.

While reading sysctl_fib_sync_mem, it can be changed concurrently.
So, we need to add READ_ONCE() to avoid a data-race.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7c1acd98fb221dc0d847451b9ab86319f8b9916c
CVE-2022-49638: kernel: icmp: Fix data-races around sysctl.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

A flaw was found in the Linux kernel's ICMP protocol. A race condition can occur when reading the ICMP sysctl variables due to a missing lock, potentially impacting system stability and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

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

Affected upstream versions: 3.18
Fixed upstream versions: 0, 4.14.289, 4.19.253, 4.9.324, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1740e5922fbb705637ae9fa5203db132fc45f9f6
CVE-2022-49639: kernel: cipso: Fix data-races around sysctl.
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

cipso: Fix data-races around sysctl.

While reading cipso sysctl variables, they can be changed concurrently.
So, we need to add READ_ONCE() to avoid data-races.


Affected upstream versions: 2.6.19
Fixed upstream versions: 0, 4.14.289, 4.19.253, 4.9.324, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2764f82bbc158d106693ae3ced3675cf4b963b35
CVE-2022-49641: kernel: sysctl: Fix data races in proc_douintvec().
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-02-26T00:00:00+00:00

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

sysctl: Fix data races in proc_douintvec().

A sysctl variable is accessed concurrently, and there is always a chance
of data-race.  So, all readers and writers need some basic protection to
avoid load/store-tearing.

This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()
internally to fix data-races on the sysctl side.  For now, proc_douintvec()
itself is tolerant to a data-race, but we still need to add annotations on
the other subsystem's side.


Affected upstream versions: 4.4.24 < 4.5, 4.7.7 < 4.8, 4.8
Fixed upstream versions: 0, 4.5, 4.8, 5.10.132, 5.15.56, 5.18.13, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d5d54714e329f646bd7af4994fc427d88ee68936
CVE-2022-49642: kernel: net: stmmac: dwc-qos: Disable split header for Tegra194
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-02-26T00:00:00+00:00

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

net: stmmac: dwc-qos: Disable split header for Tegra194

There is a long-standing issue with the Synopsys DWC Ethernet driver
for Tegra194 where random system crashes have been observed [0]. The
problem occurs when the split header feature is enabled in the stmmac
driver. In the bad case, a larger than expected buffer length is
received and causes the calculation of the total buffer length to
overflow. This results in a very large buffer length that causes the
kernel to crash. Why this larger buffer length is received is not clear,
however, the feedback from the NVIDIA design team is that the split
header feature is not supported for Tegra194. Therefore, disable split
header support for Tegra194 to prevent these random crashes from
occurring.

[0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2968830c9b47ce093237483c6207c61065712386
CVE-2022-49643: kernel: ima: Fix a potential integer overflow in ima_appraise_measurement
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-02-26T00:00:00+00:00

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

ima: Fix a potential integer overflow in ima_appraise_measurement

When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 388f3df7c3c8b7f2a32b9ae0a9b2f9f6ad3b1b77
CVE-2022-49644: kernel: drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()
Component: kernel
Severity: Moderate
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-02-26T00:00:00+00:00

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

drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

(cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2)


Affected upstream versions: 4.15
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 72f231b9a88abcfac9f5ddaa1a0aacb3f9f87ba5
CVE-2022-49646: kernel: wifi: mac80211: fix queue selection for mesh/OCB interfaces
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-02-26T00:00:00+00:00

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

wifi: mac80211: fix queue selection for mesh/OCB interfaces

When using iTXQ, the code assumes that there is only one vif queue for
broadcast packets, using the BE queue. Allowing non-BE queue marking
violates that assumption and txq->ac == skb_queue_mapping is no longer
guaranteed. This can cause issues with queue handling in the driver and
also causes issues with the recent ATF change, resulting in an AQL
underflow warning.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 444be5a02b77f3b7a8ac9c1a0b074fbb3bd89cd0
CVE-2022-49647: kernel: cgroup: Use separate src/dst nodes when preloading css_sets for migration
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-02-26T00:00:00+00:00

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

cgroup: Use separate src/dst nodes when preloading css_sets for migration

Each cset (css_set) is pinned by its tasks. When we're moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don't go away while we're moving tasks about. This
is done by linking cset->mg_preload_node on either the
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the
same cset->mg_preload_node for both the src and dst lists was deemed okay as
a cset can't be both the source and destination at the same time.

Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:

 #1> mkdir -p /sys/fs/cgroup/misc/a/b
 #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs
 #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &
 #4> PID=$!
 #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks
 #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs

the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.

After #3, let's say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:

 1. cgroup_migrate_add_src() is called on B for the leader.

 2. cgroup_migrate_add_src() is called on A for the other threads.

 3. cgroup_migrate_prepare_dst() is called. It scans the src list.

 4. It notices that B wants to migrate to A, so it tries to A to the dst
    list but realizes that its ->mg_preload_node is already busy.

 5. and then it notices A wants to migrate to A as it's an identity
    migration, it culls it by list_del_init()'ing its ->mg_preload_node and
    putting references accordingly.

 6. The rest of migration takes place with B on the src list but nothing on
    the dst list.

This means that A isn't held while migration is in progress. If all tasks
leave A before the migration finishes and the incoming task pins it, the
cset will be destroyed leading to use-after-free.

This is caused by overloading cset->mg_preload_node for both src and dst
preload lists. We wanted to exclude the cset from the src list but ended up
inadvertently excluding it from the dst list too.

This patch fixes the issue by separating out cset->mg_preload_node into
->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst
preloadings don't interfere with each other.


Affected upstream versions: 3.16
Fixed upstream versions: 0, 4.14.289, 4.19.253, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27
CVE-2022-49648: kernel: tracing/histograms: Fix memory leak problem
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

tracing/histograms: Fix memory leak problem

This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.

As commit 46bbe5c671e0 ("tracing: fix double free") said, the
"double free" problem reported by clang static analyzer is:
  > In parse_var_defs() if there is a problem allocating
  > var_defs.expr, the earlier var_defs.name is freed.
  > This free is duplicated by free_var_defs() which frees
  > the rest of the list.

However, if there is a problem allocating N-th var_defs.expr:
  + in parse_var_defs(), the freed 'earlier var_defs.name' is
    actually the N-th var_defs.name;
  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;

                        IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                 \
                                                                  |
          0th           1th                 (N-1)-th      N-th    V
          +-------------+-------------+-----+-------------+-----------
var_defs: | name | expr | name | expr | ... | name | expr | name | ///
          +-------------+-------------+-----+-------------+-----------

These two frees don't act on same name, so there was no "double free"
problem before. Conversely, after that commit, we get a "memory leak"
problem because the above "N-th var_defs.name" is not freed.

If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
var_defs.expr allocated, then execute on shell like:
  $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \
/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Then kmemleak reports:
  unreferenced object 0xffff8fb100ef3518 (size 8):
    comm "bash", pid 196, jiffies 4295681690 (age 28.538s)
    hex dump (first 8 bytes):
      76 31 00 00 b1 8f ff ff                          v1......
    backtrace:
      [<0000000038fe4895>] kstrdup+0x2d/0x60
      [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0
      [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110
      [<0000000066737a4c>] event_trigger_write+0x75/0xd0
      [<000000007341e40c>] vfs_write+0xbb/0x2a0
      [<0000000087fde4c2>] ksys_write+0x59/0xd0
      [<00000000581e9cdf>] do_syscall_64+0x3a/0x80
      [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0


Affected upstream versions: 4.19.149 < 4.19.253, 5.4.69 < 5.4.207, 5.8.13 < 5.9, 5.9
Fixed upstream versions: 0, 4.19.253, 5.10.132, 5.15.56, 5.18.13, 5.19, 5.4.207, 5.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: eb622d5580b9e2ff694f62da6410618bd73853cb
CVE-2022-49651: kernel: srcu: Tighten cleanup_srcu_struct() GP checks
Component: kernel
Severity: Moderate
CWE: CWE-459 (Incomplete Cleanup)
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-02-26T00:00:00+00:00

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

srcu: Tighten cleanup_srcu_struct() GP checks

Currently, cleanup_srcu_struct() checks for a grace period in progress,
but it does not check for a grace period that has not yet started but
which might start at any time.  Such a situation could result in a
use-after-free bug, so this commit adds a check for a grace period that
is needed but not yet started to cleanup_srcu_struct().


Affected upstream versions: 4.12
Fixed upstream versions: 0, 5.18.11, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e997dda6502eefbc1032d6b0da7b353c53344b07
CVE-2022-49653: kernel: i2c: piix4: Fix a memory leak in the EFCH MMIO support
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-02-26T00:00:00+00:00

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

i2c: piix4: Fix a memory leak in the EFCH MMIO support

The recently added support for EFCH MMIO regions introduced a memory
leak in that code path. The leak is caused by the fact that
release_resource() merely removes the resource from the tree but does
not free its memory. We need to call release_mem_region() instead,
which does free the memory. As a nice side effect, this brings back
some symmetry between the legacy and MMIO paths.


Affected upstream versions: 5.15.42 < 5.15.54, 5.17.10 < 5.18, 5.18
Fixed upstream versions: 0, 5.15.54, 5.18, 5.18.11, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d2bf1a6480e8d44658a8ac3bdcec081238873212