deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-21724
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()

Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()
where shifting the constant "1" (of type int) by bitmap->mapped.pgshift
(an unsigned long value) could result in undefined behavior.

The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds
31 (e.g., pgshift = 63) the shift operation overflows, as the result
cannot be represented in a 32-bit type.

To resolve this, the constant is updated to "1UL", promoting it to an
unsigned long type to match the operand's type.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/38ac76fc06bc6826a3e4b12a98efbe98432380a9; https://git.kernel.org/stable/c/44d9c94b7a3f29a3e07c4753603a35e9b28842a3; https://git.kernel.org/stable/c/b1f8453b8ff1ab79a03820ef608256c499769cb6
CVE: CVE-2025-21726
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

padata: avoid UAF for reorder_work

Although the previous patch can avoid ps and ps UAF for _do_serial, it
can not avoid potential UAF issue for reorder_work. This issue can
happen just as below:

crypto_request			crypto_request		crypto_del_alg
padata_do_serial
  ...
  padata_reorder
    // processes all remaining
    // requests then breaks
    while (1) {
      if (!padata)
        break;
      ...
    }

				padata_do_serial
				  // new request added
				  list_add
    // sees the new request
    queue_work(reorder_work)
				  padata_reorder
				    queue_work_on(squeue->work)
...

				<kworker context>
				padata_serial_worker
				// completes new request,
				// no more outstanding
				// requests

							crypto_del_alg
							  // free pd

<kworker context>
invoke_padata_reorder
  // UAF of pd

To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work'
into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4c6209efea2208597dbd3e52dc87a0d1a8f2dbe1; https://git.kernel.org/stable/c/6f45ef616775b0ce7889b0f6077fc8d681ab30bc; https://git.kernel.org/stable/c/7000507bb0d2ceb545c0a690e0c707c897d102c2
CVE: CVE-2025-21727
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

padata: fix UAF in padata_reorder

A bug was found when run ltp test:

BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0
Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206

CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
Workqueue: pdecrypt_parallel padata_parallel_worker
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
print_address_description.constprop.0+0x6b/0x3d0
print_report+0xdd/0x2c0
kasan_report+0xa5/0xd0
padata_find_next+0x29/0x1a0
padata_reorder+0x131/0x220
padata_parallel_worker+0x3d/0xc0
process_one_work+0x2ec/0x5a0

If 'mdelay(10)' is added before calling 'padata_find_next' in the
'padata_reorder' function, this issue could be reproduced easily with
ltp test (pcrypt_aead01).

This can be explained as bellow:

pcrypt_aead_encrypt
...
padata_do_parallel
refcount_inc(&pd->refcnt); // add refcnt
...
padata_do_serial
padata_reorder // pd
while (1) {
padata_find_next(pd, true); // using pd
queue_work_on
...
padata_serial_worker				crypto_del_alg
padata_put_pd_cnt // sub refcnt
						padata_free_shell
						padata_put_pd(ps->pd);
						// pd is freed
// loop again, but pd is freed
// call padata_find_next, UAF
}

In the padata_reorder function, when it loops in 'while', if the alg is
deleted, the refcnt may be decreased to 0 before entering
'padata_find_next', which leads to UAF.

As mentioned in [1], do_serial is supposed to be called with BHs disabled
and always happen under RCU protection, to address this issue, add
synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls
to finish.

[1] https://lore.kernel.org/all/[PII_REDACTED]0401.cccypv4euxikusiq@parnassus.localdomain/
[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd; https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738; https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781
CVE: CVE-2025-21728
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change `irqs_disabled()` to `!preemptible()`.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/092fc76b7ab4163e008f9cde596a58dad2108260; https://git.kernel.org/stable/c/78b97783496b[PII_REDACTED]37db3303e900a24d3f; https://git.kernel.org/stable/c/87c544108b612512b254c8f79aa5c0a8546e2cc4
CVE: CVE-2025-21731
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: don't allow reconnect after disconnect

Following process can cause nbd_config UAF:

1) grab nbd_config temporarily;

2) nbd_genl_disconnect() flush all recv_work() and release the
initial reference:

  nbd_genl_disconnect
   nbd_disconnect_and_put
    nbd_disconnect
     flush_workqueue(nbd->recv_workq)
    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))
     nbd_config_put
     -> due to step 1), reference is still not zero

3) nbd_genl_reconfigure() queue recv_work() again;

  nbd_genl_reconfigure
   config = nbd_get_config_unlocked(nbd)
   if (!config)
   -> succeed
   if (!test_bit(NBD_RT_BOUND, ...))
   -> succeed
   nbd_reconnect_socket
    queue_work(nbd->recv_workq, &args->work)

4) step 1) release the reference;

5) Finially, recv_work() will trigger UAF:

  recv_work
   nbd_config_put(nbd)
   -> nbd_config is freed
   atomic_dec(&config->recv_threads)
   -> UAF

Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so
that nbd_genl_reconfigure() will fail.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/6bef6222a3f6c7adb6396f77f25a3579d821b09a; https://git.kernel.org/stable/c/844b8cdc681612ff24df62cdefddeab5772fadf1; https://git.kernel.org/stable/c/9793bd5ae4bdbdb2dde401a3cab94a6bfd05e302
CVE: CVE-2024-49570
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/tracing: Fix a potential TP_printk UAF

The commit
afd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format")
exposes potential UAFs in the xe_bo_move trace event.

Fix those by avoiding dereferencing the
xe_mem_type_to_name[] array at TP_printk time.

Since some code refactoring has taken place, explicit backporting may
be needed for kernels older than 6.10.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/07089083a526ea19daa72a1edf9d6e209615b77c; https://git.kernel.org/stable/c/62cd174616ae3bf8a6cf468718f1ae74e5a07727; https://git.kernel.org/stable/c/c9402da34611e1039ecccba3c1481c4866f7ca64
CVE: CVE-2024-52557
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get()

This patch fixes a potential integer overflow in the zynqmp_dp_rate_get()

The issue comes up when the expression
drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 is evaluated using 32-bit
Now the constant is a compatible 64-bit type.

Resolves coverity issues: CID 1636340 and CID 1635811
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/325d889c5403ba20a24097f64c32d27ab993c2c3; https://git.kernel.org/stable/c/67a615c5cb6dc33ed35492dc0d67e496cbe8de68
CVE: CVE-2024-52559
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()

The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.

Patchwork: https://patchwork.freedesktop.org/patch/624696/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/2b99b2c4621d13bd4374ef384e8f1fc188d0a5df; https://git.kernel.org/stable/c/2f1845e46c41ed500789d53dc45b383b7745c96c; https://git.kernel.org/stable/c/3a47f4b439beb98e955d501c609dfd12b7836d61
CVE: CVE-2024-52560
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()

Extended the `mi_enum_attr()` function interface with an additional
parameter, `struct ntfs_inode *ni`, to allow marking the inode
as bad as soon as an error is detected.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2afd4d267e6dbaec8d3ccd4f5396cb84bc67aa2e; https://git.kernel.org/stable/c/d9c699f2c4dc174940ffe8600b20c267897da155
CVE: CVE-2024-54456
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()

name is char[64] where the size of clnt->cl_program->name remains
unknown. Invoking strcat() directly will also lead to potential buffer
overflow. Change them to strscpy() and strncat() to fix potential
issues.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/19b3ca651b4b473878c73539febe[PII_REDACTED]42; https://git.kernel.org/stable/c/49fd4e34751e90e6df009b70cd0659dc839e7ca8; https://git.kernel.org/stable/c/dd8830779b77f4d1206d28d02ad56a03fc0e78f7
CVE: CVE-2024-54458
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: bsg: Set bsg_queue to NULL after removal

Currently, this does not cause any issues, but I believe it is necessary to
set bsg_queue to NULL after removing it to prevent potential use-after-free
(UAF) access.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1e95c798d8a7f70965f0f88d4657b682ff0ec75f; https://git.kernel.org/stable/c/22018622e1e9e371198dbd983af946a844d5924c; https://git.kernel.org/stable/c/5e7b6e44468c3242c21c2a8656d009fb3eb50a73
CVE: CVE-2024-57834
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread

syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]

If dvb->mux is not initialized successfully by vidtv_mux_init() in the
vidtv_start_streaming(), it will trigger null pointer dereference about mux
in vidtv_mux_stop_thread().

Adjust the timing of streaming initialization and check it before
stopping it.

[1]
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000128-0x[PII_REDACTED]00012f]
CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471
Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8
RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202
RAX: dffffc[PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffffff87cfb125
RDX: [PII_REDACTED] RSI: ffffffff87d120ce RDI: [PII_REDACTED]
RBP: ffff888029b8d220 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff888029b8d188
R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710
FS:  00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f7eef5e635c CR3:[PII_REDACTED]ca6000 CR4:[PII_REDACTED]3526f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]
 vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252
 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000
 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486
 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559
 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]
 dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246
 __fput+0x3f8/0xb60 fs/file_table.c:450
 task_work_run+0x14e/0x250 kernel/task_work.c:239
 get_signal+0x1d3/0x2610 kernel/signal.c:2790
 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337
 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]db711578a327a9367f1be46500cb48; https://git.kernel.org/stable/c/2c5601b99d79d196fe4a37159e3dfb38e778ea18; https://git.kernel.org/stable/c/52d3512f9a7a52ef92864679b1e8e8aa16202c6a
CVE: CVE-2024-57852
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: qcom: scm: smc: Handle missing SCM device

Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer
dereference") makes it explicit that qcom_scm_get_tzmem_pool() can
return NULL, therefore its users should handle this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/57a811c0886f3f3677bb4619502b35b5bb917f2e; https://git.kernel.org/stable/c/94f48ecf0a538019ca2025e0b0da391f8e7cc58c; https://git.kernel.org/stable/c/cd955b75849b58b650ca3f87b83bd78cde1da8bc
CVE: CVE-2024-58001
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a
giant patch for review ;-)

So I've redone it as individual patches, and credited Mark for the patches
where his code is substantially the same.  It's not a bad way to do it;
his patch had some bugs and my patches had some bugs.  Hopefully all our
bugs were different from each other.  And hopefully Mark likes all the
changes I made to his code!


This patch (of 23):

If we can't read the buffer, be sure to unlock the page before returning.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b4c2094da6d84e69b843dd3317902e977bf64bd; https://git.kernel.org/stable/c/52a326f93ceb9348264fddf7bab6e345db69e08c; https://git.kernel.org/stable/c/5e3b3ec7c3cb5ba5629a766e4f0926db72cf0a1f
CVE: CVE-2024-58002
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Remove dangling pointers

When an async control is written, we copy a pointer to the file handle
that started the operation. That pointer will be used when the device is
done. Which could be anytime in the future.

If the user closes that file descriptor, its structure will be freed,
and there will be one dangling pointer per pending async control, that
the driver will try to use.

Clean all the dangling pointers during release().

To avoid adding a performance penalty in the most common case (no async
operation), a counter has been introduced with some logic to make sure
that it is properly handled.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/117f7a2975baa4b7d702d3f4830d5a4ebd0c6d50; https://git.kernel.org/stable/c/221cd51efe4565501a3dbf04cc011b537dcce7fb; https://git.kernel.org/stable/c/2a29413ace64627e178fd422dd8a5d95219a2c0b
CVE: CVE-2024-58003
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()

The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) as
part of their remove process, and if the driver is removed multiple
times, eventually leads to put "overflow", possibly causing memory
corruption or crash.

The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:
i2c: ds90ub9x3: Fix sub-device matching"), which changed the code
related to the sd.fwnode, but missed removing these fwnode_handle_put()
calls.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/474d7baf91d37bc411fa60de5bbf03c9dd82e18a; https://git.kernel.org/stable/c/60b45ece41c5632a3a3274115a401cb244180646; https://git.kernel.org/stable/c/70743d6a8b[PII_REDACTED]11e7983825f1be86062d
CVE: CVE-2024-58004
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: intel/ipu6: remove cpu latency qos request on error

Fix cpu latency qos list corruption like below. It happens when
we do not remove cpu latency request on error path and free
corresponding memory.

[   30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was [PII_REDACTED]. (prev=ffff8e9e877e20a8).
[   30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0
<snip>
[   30.634640] l7 kernel: Call Trace:
[   30.634650] l7 kernel:  <TASK>
[   30.634659] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634669] l7 kernel:  ? __warn.cold+0x93/0xf6
[   30.634678] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634690] l7 kernel:  ? report_bug+0xff/0x140
[   30.634702] l7 kernel:  ? handle_bug+0x58/0x90
[   30.634712] l7 kernel:  ? exc_invalid_op+0x17/0x70
[   30.634723] l7 kernel:  ? asm_exc_invalid_op+0x1a/0x20
[   30.634733] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634742] l7 kernel:  plist_add+0xdd/0x140
[   30.634754] l7 kernel:  pm_qos_update_target+0xa0/0x1f0
[   30.634764] l7 kernel:  cpu_latency_qos_update_request+0x61/0xc0
[   30.634773] l7 kernel:  intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1496ec94bd38bdb25ca13b1dd4f8e7a6176ea89d; https://git.kernel.org/stable/c/[PII_REDACTED]5ecb71dc97a71d8d9d19e4ffb0a9eb; https://git.kernel.org/stable/c/facb541ff0805314e0b56e508f7d3cbd07af513c
CVE: CVE-2024-58005
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: Change to kvalloc() in eventlog/acpi.c

The following failure was reported on HPE ProLiant D320:

[   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
[   10.848132][    T1] ------------[ cut here ]------------
[   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
[   10.862827][    T1] Modules linked in:
[   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
[   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
[   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
[   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
[   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
[   10.923777][    T1] RAX: [PII_REDACTED] RBX:[PII_REDACTED]040cc0 RCX: [PII_REDACTED]
[   10.931727][    T1] RDX: [PII_REDACTED] RSI:[PII_REDACTED]00000c RDI:[PII_REDACTED]040cc0

The above transcript shows that ACPI pointed a 16 MiB buffer for the log
events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
Address the bug by moving from devm_kmalloc() to devm_add_action() and
kvmalloc() and devm_add_action().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0621d2599d6e02d05c85d6bbd58eaea2f15b3503; https://git.kernel.org/stable/c/422d7f4e8d817be467986589c7968d3ea402f7da; https://git.kernel.org/stable/c/4c8bfe643bbd00b04ee8f9545ef33bf6a68c38db
CVE: CVE-2024-58006
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.

This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).

This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.

If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.

While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3229c15d6267de8e704b4085df8a82a5af2d63eb; https://git.kernel.org/stable/c/3708acbd5f169ebafe1faa519cb28adc56295546; https://git.kernel.org/stable/c/b5cacfd067060c75088363ed3e19779078be2755
CVE: CVE-2024-58007
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: socinfo: Avoid out of bounds read of serial number

On MSM8916 devices, the serial number exposed in sysfs is constant and does
not change across individual devices. It's always:

  db410c:/sys/devices/soc0$ cat serial_number
 [PII_REDACTED]

The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not
have support for the serial_num field in the socinfo struct. There is an
existing check to avoid exposing the serial number in that case, but it's
not correct: When checking the item_size returned by SMEM, we need to make
sure the *end* of the serial_num is within bounds, instead of comparing
with the *start* offset. The serial_number currently exposed on MSM8916
devices is just an out of bounds read of whatever comes after the socinfo
struct in SMEM.

Fix this by changing offsetof() to offsetofend(), so that the size of the
field is also taken into account.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0a92feddae0634a0b87c04b19d343f6af97af700; https://git.kernel.org/stable/c/22cf4fae6660b6e1a583a41cbf84e3046ca9ccd0; https://git.kernel.org/stable/c/2495c6598731b6d7f565140f2bd63ef4bc36ce7d
CVE: CVE-2024-58008
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y

With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted
keys can crash during en- and decryption of the blob encryption key via
the DCP crypto driver. This is caused by improperly using sg_init_one()
with vmalloc'd stack buffers (plain_key_blob).

Fix this by always using kmalloc() for buffers we give to the DCP crypto
driver.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3192f1c54dddb9b5820bf5e[PII_REDACTED]d8e9c66; https://git.kernel.org/stable/c/3355594de46fb1cba663f12b9644b664b8a609f4; https://git.kernel.org/stable/c/e8d9fab39d1f87b52932646b2f1e7877aa3fc0f4