huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
CVE: CVE-2025-12838
Component: MSP360 Free Backup Link Following Local Privilege Escalation Vulnerability
Release date: 2025-11-11T23:25:20.386000+00:00

MSP360 Free Backup Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of MSP360 Free Backup. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. User interaction on the part of an administrator is needed additionally.

The specific flaw exists within the restore functionality. By creating a junction, an attacker can abuse the service to create arbitrary files. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-27245.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
slab: Avoid race on slab->obj_exts in alloc_slab_obj_exts
CVE: CVE-2025-40348
Component: kernel
CWE: CWE-476
Severity: Important
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-12-16T00:00:00+00:00

A race condition was found in the Linux kernel's slab allocator. When two threads concurrently call alloc_slab_obj_exts() and one fails allocation, it may overwrite the other's valid obj_exts pointer with OBJEXTS_ALLOC_FAIL. The winning thread later dereferences this as a valid pointer, causing a null pointer dereference.

Statement: This race exists in core memory allocation code but requires CONFIG_SLUB_DEBUG or CONFIG_MEMCG_KMEM enabled with specific concurrent allocation patterns. The fix uses cmpxchg for atomic updates.

Remediation:
Linux kernel: Use-After-Free vulnerability in ATM subsystem
CVE: CVE-2025-38180
Component: kernel
CWE: CWE-911
Severity: Moderate
CVSS v3: 7.2/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Release date: 2025-07-04T00:00:00+00:00

A flaw was found in the Linux kernel's Asynchronous Transfer Mode (ATM) subsystem. An authenticated local attacker could exploit a Use-After-Free (UAF) vulnerability in the /proc/net/atm/lec handling. This flaw occurs due to improper dev_put() calls without prior dev_hold() calls, leading to an imbalance in reference counting. Successful exploitation could allow the attacker to achieve privilege escalation or cause a denial of service.


Remediation:
MySQL Server: Denial of Service vulnerability via network access by a high privileged attacker
CVE: CVE-2025-21525
Component: mysql
Severity: Moderate
CVSS v3: 5.9/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-21T20:53:06.259000+00:00

A flaw was found in MySQL Server. This vulnerability allows a high privileged remote attacker to cause a complete Denial of Service.


Remediation:
misc: fastrpc: fix possible map leak in fastrpc_put_args
CVE: CVE-2025-40036
Component: kernel
Severity: None
Release date: 2025-10-28T00:00:00+00:00

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

misc: fastrpc: fix possible map leak in fastrpc_put_args

copy_to_user() failure would cause an early return without cleaning up
the fdlist, which has been updated by the DSP. This could lead to map
leak. Fix this by redirecting to a cleanup path on failure, ensuring
that all mapped buffers are properly released before returning.


Remediation:
rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access
CVE: CVE-2025-38704
Component: kernel
Severity: None
Release date: 2025-09-04T00:00:00+00:00

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

rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access

In the preparation stage of CPU online, if the corresponding
the rdp's->nocb_cb_kthread does not exist, will be created,
there is a situation where the rdp's rcuop kthreads creation fails,
and then de-offload this CPU's rdp, does not assign this CPU's
rdp->nocb_cb_kthread pointer, but this rdp's->nocb_gp_rdp and
rdp's->rdp_gp->nocb_gp_kthread is still valid.

This will cause the subsequent re-offload operation of this offline
CPU, which will pass the conditional check and the kthread_unpark()
will access invalid rdp's->nocb_cb_kthread pointer.

This commit therefore use rdp's->nocb_gp_kthread instead of
rdp_gp's->nocb_gp_kthread for safety check.


Remediation:
io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths
CVE: CVE-2025-39816
Component: kernel
CWE: CWE-367
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Release date: 2025-09-16T00:00:00+00:00

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

io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths

Since the buffers are mapped from userspace, it is prudent to use
READ_ONCE() to read the value into a local variable, and use that for
any other actions taken. Having a stable read of the buffer length
avoids worrying about it changing after checking, or being read multiple
times.

Similarly, the buffer may well change in between it being picked and
being committed. Ensure the looping for incremental ring buffer commit
stops if it hits a zero sized buffer, as no further progress can be made
at that point.

Statement: This vulnerability is rated Moderate for Red Hat Enterprise Linux 10.x. The flaw exists in the io_uring/kbuf component of the kernel, where improper handling of ring provided buffer lengths from userspace could lead to an issue. Red Hat Enterprise Linux 6, 7, 8, and 9 are not affected as the vulnerable code is not present in these versions. If triggered, this vulnerability affects integrity and availability, as the bug can cause inconsistent internal states and lead to stalls or system instability in the io_uring subsystem.

Remediation:
soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()
CVE: CVE-2025-23148
Component: kernel
Severity: None
Release date: 2025-05-01T00:00:00+00:00

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

soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()

soc_dev_attr->revision could be NULL, thus,
a pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.


Remediation:
media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()
CVE: CVE-2025-68819
Component: kernel
CWE: CWE-120
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
Release date: 2025-01-01T00:00:00+00:00

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

media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()

rlen value is a user-controlled value, but dtv5100_i2c_msg() does not
check the size of the rlen value. Therefore, if it is set to a value
larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.

Therefore, we need to add proper range checking to prevent this vuln.


Remediation:
drm/msm/gpu: Fix crash when throttling GPU immediately during boot
CVE: CVE-2025-38354
Component: kernel
Severity: None
Release date: 2025-07-25T00:00:00+00:00

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

drm/msm/gpu: Fix crash when throttling GPU immediately during boot

There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:

  Unable to handle kernel paging request at virtual address 0000000000014110
  pc : a6xx_gpu_busy+0x1c/0x58 [msm]
  lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
  Call trace:
   a6xx_gpu_busy+0x1c/0x58 [msm] (P)
   devfreq_simple_ondemand_func+0x3c/0x150
   devfreq_update_target+0x44/0xd8
   qos_max_notifier_call+0x30/0x84
   blocking_notifier_call_chain+0x6c/0xa0
   pm_qos_update_target+0xd0/0x110
   freq_qos_apply+0x3c/0x74
   apply_constraint+0x88/0x148
   __dev_pm_qos_update_request+0x7c/0xcc
   dev_pm_qos_update_request+0x38/0x5c
   devfreq_cooling_set_cur_state+0x98/0xf0
   __thermal_cdev_update+0x64/0xb4
   thermal_cdev_update+0x4c/0x58
   step_wise_manage+0x1f0/0x318
   __thermal_zone_device_update+0x278/0x424
   __thermal_cooling_device_register+0x2bc/0x308
   thermal_of_cooling_device_register+0x10/0x1c
   of_devfreq_cooling_register_power+0x240/0x2bc
   of_devfreq_cooling_register+0x14/0x20
   msm_devfreq_init+0xc4/0x1a0 [msm]
   msm_gpu_init+0x304/0x574 [msm]
   adreno_gpu_init+0x1c4/0x2e0 [msm]
   a6xx_gpu_init+0x5c8/0x9c8 [msm]
   adreno_bind+0x2a8/0x33c [msm]
   ...

At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
accordingly. This means the df->suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.

Fix this by setting df->suspended correctly during initialization.

Patchwork: https://patchwork.freedesktop.org/patch/650772/


Remediation:
crypto: null - Use spin lock instead of mutex
CVE: CVE-2025-37808
Component: kernel
CWE: CWE-667
Severity: Moderate
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-05-08T00:00:00+00:00

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

crypto: null - Use spin lock instead of mutex

As the null algorithm may be freed in softirq context through
af_alg, use spin locks instead of mutexes to protect the default
null algorithm.


Remediation:
Nomad Vulnerable To Event Stream Namespace ACL Policy Bypass Through Wildcard Namespace
CVE: CVE-2025-0937
Component: nomad
CWE: CWE-863
Severity: Important
CVSS v3: 7.3/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Release date: 2025-02-12T18:59:25.011000+00:00

A flaw was discovered in Hashicorp Nomad. In affected versions of this package, the vulnerability is exploitable when reading from the event stream endpoint with a wildcard namespace, which can be used to bypass the ACL policy checks that would not otherwise permit access to a given namespace due to a discrepancy in how ACL wildcards are validated.

Statement: HashiCorp Nomad is a third party dependency in Red Hat Distributed Tracing. The affected codebase of HashiCorp Nomad is not shipped in Red Hat Distributed Tracing.

Remediation:
No mitigation is available for this issue other than updating the affected package to the version containing the fix.
iommu/vt-d: Fix suspicious RCU usage
CVE: CVE-2025-21876
Component: kernel
Severity: Low
CVSS v3: 3.4/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-03-27T00:00:00+00:00

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

iommu/vt-d: Fix suspicious RCU usage

Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts
locally") moved the call to enable_drhd_fault_handling() to a code
path that does not hold any lock while traversing the drhd list. Fix
it by ensuring the dmar_global_lock lock is held when traversing the
drhd list.

Without this fix, the following warning is triggered:
 =============================
 WARNING: suspicious RCU usage
 6.14.0-rc3 #55 Not tainted
 -----------------------------
 drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!
               other info that might help us debug this:
               rcu_scheduler_active = 1, debug_locks = 1
 2 locks held by cpuhp/1/23:
 #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 stack backtrace:
 CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55
 Call Trace:
  <TASK>
  dump_stack_lvl+0xb7/0xd0
  lockdep_rcu_suspicious+0x159/0x1f0
  ? __pfx_enable_drhd_fault_handling+0x10/0x10
  enable_drhd_fault_handling+0x151/0x180
  cpuhp_invoke_callback+0x1df/0x990
  cpuhp_thread_fun+0x1ea/0x2c0
  smpboot_thread_fn+0x1f5/0x2e0
  ? __pfx_smpboot_thread_fn+0x10/0x10
  kthread+0x12a/0x2d0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x4a/0x60
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  </TASK>

Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat
about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.
This is avoided by not holding dmar_global_lock when calling
iommu_device_register(), which initiates the device probe process.


Remediation:
tracing: Fix bad hist from corrupting named_triggers list
CVE: CVE-2025-21899
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 5.2/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H
Release date: 2025-04-01T00:00:00+00:00

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

tracing: Fix bad hist from corrupting named_triggers list

The following commands causes a crash:

 ~# cd /sys/kernel/tracing/events/rcu/rcu_callback
 ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger
 bash: echo: write error: Invalid argument
 ~# echo 'hist:name=bad:keys=common_pid' > trigger

Because the following occurs:

event_trigger_write() {
  trigger_process_regex() {
    event_hist_trigger_parse() {

      data = event_trigger_alloc(..);

      event_trigger_register(.., data) {
        cmd_ops->reg(.., data, ..) [hist_register_trigger()] {
          data->ops->init() [event_hist_trigger_init()] {
            save_named_trigger(name, data) {
              list_add(&data->named_list, &named_triggers);
            }
          }
        }
      }

      ret = create_actions(); (return -EINVAL)
      if (ret)
        goto out_unreg;
[..]
      ret = hist_trigger_enable(data, ...) {
        list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)
[..]
 out_unreg:
      event_hist_unregister(.., data) {
        cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] {
          list_for_each_entry(iter, &file->triggers, list) {
            if (!hist_trigger_match(data, iter, named_data, false))   <- never matches
                continue;
            [..]
            test = iter;
          }
          if (test && test->ops->free) <<<-- test is NULL

            test->ops->free(test) [event_hist_trigger_free()] {
              [..]
              if (data->name)
                del_named_trigger(data) {
                  list_del(&data->named_list);  <<<<-- NEVER gets removed!
                }
              }
           }
         }

         [..]
         kfree(data); <<<-- frees item but it is still on list

The next time a hist with name is registered, it causes an u-a-f bug and
the kernel can crash.

Move the code around such that if event_trigger_register() succeeds, the
next thing called is hist_trigger_enable() which adds it to the list.

A bunch of actions is called if get_named_trigger_data() returns false.
But that doesn't need to be called after event_trigger_register(), so it
can be moved up, allowing event_trigger_register() to be called just
before hist_trigger_enable() keeping them together and allowing the
file->triggers to be properly populated.


Remediation:
arm: pgtable: fix NULL pointer dereference issue
CVE: CVE-2025-21933
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-04-01T00:00:00+00:00

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

arm: pgtable: fix NULL pointer dereference issue

When update_mmu_cache_range() is called by update_mmu_cache(), the vmf
parameter is NULL, which will cause a NULL pointer dereference issue in
adjust_pte():

Unable to handle kernel NULL pointer dereference at virtual address 00000030 when read
Hardware name: Atmel AT91SAM9
PC is at update_mmu_cache_range+0x1e0/0x278
LR is at pte_offset_map_rw_nolock+0x18/0x2c
Call trace:
 update_mmu_cache_range from remove_migration_pte+0x29c/0x2ec
 remove_migration_pte from rmap_walk_file+0xcc/0x130
 rmap_walk_file from remove_migration_ptes+0x90/0xa4
 remove_migration_ptes from migrate_pages_batch+0x6d4/0x858
 migrate_pages_batch from migrate_pages+0x188/0x488
 migrate_pages from compact_zone+0x56c/0x954
 compact_zone from compact_node+0x90/0xf0
 compact_node from kcompactd+0x1d4/0x204
 kcompactd from kthread+0x120/0x12c
 kthread from ret_from_fork+0x14/0x38
Exception stack(0xc0d8bfb0 to 0xc0d8bff8)

To fix it, do not rely on whether 'ptl' is equal to decide whether to hold
the pte lock, but decide it by whether CONFIG_SPLIT_PTE_PTLOCKS is
enabled.  In addition, if two vmas map to the same PTE page, there is no
need to hold the pte lock again, otherwise a deadlock will occur.  Just
add the need_lock parameter to let adjust_pte() know this information.


Remediation:
Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure
CVE: CVE-2025-38641
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 6.6/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-08-22T00:00:00+00:00

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

Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure

Avoid potential NULL pointer dereference by checking the return value of
kmalloc and handling allocation failure properly.


Remediation:
cgroup: split cgroup_destroy_wq into 3 workqueues
CVE: CVE-2025-39953
Component: kernel
Severity: Low
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-10-04T00:00:00+00:00

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

cgroup: split cgroup_destroy_wq into 3 workqueues

A hung task can occur during [1] LTP cgroup testing when repeatedly
mounting/unmounting perf_event and net_prio controllers with
systemd.unified_cgroup_hierarchy=1. The hang manifests in
cgroup_lock_and_drain_offline() during root destruction.

Related case:
cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event
cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio

Call Trace:
	cgroup_lock_and_drain_offline+0x14c/0x1e8
	cgroup_destroy_root+0x3c/0x2c0
	css_free_rwork_fn+0x248/0x338
	process_one_work+0x16c/0x3b8
	worker_thread+0x22c/0x3b0
	kthread+0xec/0x100
	ret_from_fork+0x10/0x20

Root Cause:

CPU0                            CPU1
mount perf_event                umount net_prio
cgroup1_get_tree                cgroup_kill_sb
rebind_subsystems               // root destruction enqueues
				// cgroup_destroy_wq
// kill all perf_event css
                                // one perf_event css A is dying
                                // css A offline enqueues cgroup_destroy_wq
                                // root destruction will be executed first
                                css_free_rwork_fn
                                cgroup_destroy_root
                                cgroup_lock_and_drain_offline
                                // some perf descendants are dying
                                // cgroup_destroy_wq max_active = 1
                                // waiting for css A to die

Problem scenario:
1. CPU0 mounts perf_event (rebind_subsystems)
2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work
3. A dying perf_event CSS gets queued for offline after root destruction
4. Root destruction waits for offline completion, but offline work is
   blocked behind root destruction in cgroup_destroy_wq (max_active=1)

Solution:
Split cgroup_destroy_wq into three dedicated workqueues:
cgroup_offline_wq – Handles CSS offline operations
cgroup_release_wq – Manages resource release
cgroup_free_wq – Performs final memory deallocation

This separation eliminates blocking in the CSS free path while waiting for
offline operations to complete.

[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers


Remediation:
net/ip6_tunnel: Prevent perpetual tunnel growth
CVE: CVE-2025-40173
Component: kernel
CWE: CWE-122
Severity: Moderate
CVSS v3: 4.4/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-12T00:00:00+00:00

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

net/ip6_tunnel: Prevent perpetual tunnel growth

Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.
While ipv4 tunnel headroom adjustment growth was limited in
commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),
ipv6 tunnel yet increases the headroom without any ceiling.

Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.

Credits to Francesco Ruggeri, who was originally debugging this issue
and wrote local Arista-specific patch and a reproducer.

Statement: This patch fixes an issue where IPv6 tunnels could grow dev->needed_headroom without bounds, eventually causing out-of-range headroom expansions and corruption of skb metadata.
A local user with the ability to create or configure IPv6 tunnels (CAP_NET_ADMIN) could trigger oversized allocations leading to kernel panic or memory corruption.
For the CVSS the Privilege requirement is PR:H because only privileged networking operations (tunnel creation / management) can influence headroom calculations, and unprivileged users cannot trigger this behavior directly.

Remediation:
thunderbird: Fullscreen notification not properly displayed
CVE: CVE-2025-1019
Component: firefox
CWE: CWE-451
Severity: Moderate
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Release date: 2025-02-04T13:58:54.064000+00:00

The z-order of the browser windows could be manipulated to hide the fullscreen notification. This could potentially be leveraged to perform a spoofing attack. This vulnerability affects Firefox < 135 and Thunderbird < 135.

Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.

Remediation:
Kernel: Resource management flaw in RDMA/core can lead to denial of service
CVE: CVE-2025-71157
Component: kernel
CWE: CWE-911
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
Release date: 2025-01-01T00:00:00+00:00

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

RDMA/core: always drop device refcount in ib_del_sub_device_and_put()

Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add
support to add/delete a sub IB device through netlink") grabs a reference
using ib_device_get_by_index() before calling ib_del_sub_device_and_put(),
we need to drop that reference before returning -EOPNOTSUPP error.


Remediation:
crypto: ccp - Fix dereferencing uninitialized error pointer
CVE: CVE-2025-39729
Component: kernel
Severity: None
Release date: 2025-09-07T00:00:00+00:00

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

crypto: ccp - Fix dereferencing uninitialized error pointer

Fix below smatch warnings:
drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked()
error: we previously assumed 'error' could be null


Remediation:
coresight: ETR: Fix ETR buffer use-after-free issue
CVE: CVE-2025-68376
Component: kernel
Severity: None
Release date: 2025-12-24T00:00:00+00:00

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

coresight: ETR: Fix ETR buffer use-after-free issue

When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed
and enabled again, currently sysfs_buf will point to the newly
allocated memory(buf_new) and free the old memory(buf_old). But the
etr_buf that is being used by the ETR remains pointed to buf_old, not
updated to buf_new. In this case, it will result in a memory
use-after-free issue.

Fix this by checking ETR's mode before updating and releasing buf_old,
if the mode is CS_MODE_SYSFS, then skip updating and releasing it.


Remediation: