deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-56685
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe

Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy
Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero
length, and only gets populated with the dummy struct after the card is
registered. Since the sound card driver's probe happens before the card
registration, accessing any of the members of a dummy component during
probe will result in undefined behavior.

This can be observed in the mt8188 and mt8195 machine sound drivers. By
omitting a dai link subnode in the sound card's node in the Devicetree,
the default uninitialized dummy codec is used, and when its dai_name
pointer gets passed to strcmp() it results in a null pointer dereference
and a kernel panic.

In addition to that, set_card_codec_info() in the generic helpers file,
mtk-soundcard-driver.c, will populate a dai link with a dummy codec when
a dai link node is present in DT but with no codec property.

The result is that at probe time, a dummy codec can either be
uninitialized with num_codecs = 0, or be an initialized dummy codec,
with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to
accommodate for both situations, check that num_codecs is not zero
before accessing the codecs' fields but still check for the codec's dai
name against "snd-soc-dummy-dai" as needed.

While at it, also drop the check that dai_name is not null in the mt8192
driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192:
Check existence of dai_name before dereferencing"), as it is actually
redundant given the preceding num_codecs != 0 check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/2f2020327cc8561d7c520d2f2d9acea84fa7b3a3; https://git.kernel.org/stable/c/376f4800f34a28def026ff5c5d4fc5e54e1744ff; https://git.kernel.org/stable/c/550279449ff54c5aa28cfca5c567308cbfb145f0
CVE: CVE-2024-56686
Published: 2024-12-28
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-56688
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport

Since transport->sock has been set to NULL during reset transport,
XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the
xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()
to dereference the transport->sock that has been set to NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3811172e8c98ceebd12fe526ca6cb37a1263c964; https://git.kernel.org/stable/c/4db9ad82a6c823094da27de4825af693a3475d51; https://git.kernel.org/stable/c/638a8fa5a7e641f9401346c57e236f02379a0c40
CVE: CVE-2024-56689
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'

If platform_get_resource_byname() fails and returns NULL because DT lacks
an 'mmio' property for the MHI endpoint, dereferencing res->start will
cause a NULL pointer access. Add a check to prevent it.

[kwilczynski: error message update per the review feedback]
[bhelgaas: commit log]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0e6d92e3b973de78eb7015154cf1197af9fac5c9; https://git.kernel.org/stable/c/242ee2b0ad9b23f47084904fce3f9f228068a1f9; https://git.kernel.org/stable/c/5089b3d874e9933d9842e90410d3af[PII_REDACTED]
CVE: CVE-2024-56690
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for
PADATA_RESET"), the pcrypt encryption and decryption operations return
-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is
generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns
-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.
Fix this issue by calling crypto layer directly without parallelization
in that case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5edae7a9a35606017ee6e05911c290acee9fee5a; https://git.kernel.org/stable/c/662f2f13e66d3883b9238b0b96b17886179e60e2; https://git.kernel.org/stable/c/7ddab756f2de5b7b43c122ebebdf37f400fb2b6f
CVE: CVE-2024-56691
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device

While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0997e77c51330c2866a4f39480e762cca92ad953; https://git.kernel.org/stable/c/0b648968bfa4f5c9c4983bca9f2de17626ed6fb6; https://git.kernel.org/stable/c/23230ac3c5ca3f154b64849d1cf50583b4e6b98c
CVE: CVE-2024-56692
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on node blkaddr in truncate_node()

syzbot reports a f2fs bug as below:

------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.c:2534!
RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534
Call Trace:
 truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909
 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288
 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856
 evict+0x4e8/0x9b0 fs/inode.c:723
 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986
 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394
 lookup_open fs/namei.c:3595 [inline]
 open_last_lookups fs/namei.c:3694 [inline]
 path_openat+0x1c03/0x3590 fs/namei.c:3930
 do_filp_open+0x235/0x490 fs/namei.c:3960
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415
 do_sys_open fs/open.c:1430 [inline]
 __do_sys_openat fs/open.c:1446 [inline]
 __se_sys_openat fs/open.c:1441 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1441
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534

The root cause is: on a fuzzed image, blkaddr in nat entry may be
corrupted, then it will cause system panic when using it in
f2fs_invalidate_blocks(), to avoid this, let's add sanity check on
nat blkaddr in truncate_node().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754, CWE-754
References: https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a[PII_REDACTED]8; https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d; https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d
CVE: CVE-2024-56693
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

brd: defer automatic disk creation until module initialization succeeds

My colleague Wupeng found the following problems during fault injection:

BUG: unable to handle page fault for address: fffffbfff809d073
PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:__asan_load8+0x4c/0xa0
...
Call Trace:
 <TASK>
 blkdev_put_whole+0x41/0x70
 bdev_release+0x1a3/0x250
 blkdev_release+0x11/0x20
 __fput+0x1d7/0x4a0
 task_work_run+0xfc/0x180
 syscall_exit_to_user_mode+0x1de/0x1f0
 do_syscall_64+0x6b/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

loop_init() is calling loop_add() after __register_blkdev() succeeds and
is ignoring disk_add() failure from loop_add(), for loop_add() failure
is not fatal and successfully created disks are already visible to
bdev_open().

brd_init() is currently calling brd_alloc() before __register_blkdev()
succeeds and is releasing successfully created disks when brd_init()
returns an error. This can cause UAF for the latter two case:

case 1:
    T1:
modprobe brd
  brd_init
    brd_alloc(0) // success
      add_disk
        disk_scan_partitions
          bdev_file_open_by_dev // alloc file
          fput // won't free until back to userspace
    brd_alloc(1) // failed since mem alloc error inject
  // error path for modprobe will release code segment
  // back to userspace
  __fput
    blkdev_release
      bdev_release
        blkdev_put_whole
          bdev->bd_disk->fops->release // fops is freed now, UAF!

case 2:
    T1:                            T2:
modprobe brd
  brd_init
    brd_alloc(0) // success
                                   open(/dev/ram0)
    brd_alloc(1) // fail
  // error path for modprobe

                                   close(/dev/ram0)
                                   ...
                                   /* UAF! */
                                   bdev->bd_disk->fops->release

Fix this problem by following what loop_init() does. Besides,
reintroduce brd_devices_mutex to help serialize modifications to
brd_list.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf[PII_REDACTED]0d; https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56; https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff
CVE: CVE-2024-56694
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
    write_lock_bh(&sk->sk_callback_lock)
    strp_data_ready
      strp_read_sock
        read_sock -> tcp_read_sock
          strp_recv
            cb.rcv_msg -> sk_psock_strp_read
              # now stream_verdict return SK_PASS without peer sock assign
              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
              sk_psock_verdict_apply
                sk_psock_skb_ingress_self
                  sk_psock_skb_ingress_enqueue
                    sk_psock_data_ready
                      read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72; https://git.kernel.org/stable/c/221109ba2127eabd0aa[PII_REDACTED]8b58b15df56; https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578
CVE: CVE-2024-56695
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Use dynamic allocation for CU occupancy array in 'kfd_get_cu_occupancy()'

The `kfd_get_cu_occupancy` function previously declared a large
`cu_occupancy` array as a local variable, which could lead to stack
overflows due to excessive stack usage. This commit replaces the static
array allocation with dynamic memory allocation using `kcalloc`,
thereby reducing the stack size.

This change avoids the risk of stack overflows in kernel space,  in
scenarios where `AMDGPU_MAX_QUEUES` is large. The  allocated memory is
freed using `kfree` before the function returns  to prevent memory
leaks.

Fixes the below with gcc W=1:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function ‘kfd_get_cu_occupancy’:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:322:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  322 | }
      | ^
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/6d9f07196389f35a3afebcf1a12c1425725caddd; https://git.kernel.org/stable/c/922f0e00017b09d9d47e3efac008c8b20ed546a0
CVE: CVE-2024-56696
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()

kunit_kzalloc() may return a NULL pointer, dereferencing it without
NULL check may lead to NULL dereference.
Add NULL checks for all the kunit_kzalloc() in sound_kunit.c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/8bfff486ecc79a72e9380e2d5e0ff234d5542d2f; https://git.kernel.org/stable/c/9ad467a2b2716d4ed12f003b041aa6c776a13ff5; https://git.kernel.org/stable/c/f5486bf8abfe778b368d8fd1aa655dc01d0013ca
CVE: CVE-2024-56697
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix the memory allocation issue in amdgpu_discovery_get_nps_info()

Fix two issues with memory allocation in amdgpu_discovery_get_nps_info()
for mem_ranges:

 - Add a check for allocation failure to avoid dereferencing a null
   pointer.

 - As suggested by Christophe, use kvcalloc() for memory allocation,
   which checks for multiplication overflow.

Additionally, assign the output parameters nps_type and range_cnt after
the kvcalloc() call to prevent modifying the output parameters in case
of an error return.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/a1144da794adedb9447437c57d69add56494309d; https://git.kernel.org/stable/c/d14bea4e094871226ea69772d69dab8b7b5f4915; https://git.kernel.org/stable/c/e8f1dbaa0437eba4e8c1d6a6d81eca2e2ce3d197
CVE: CVE-2024-56698
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Fix looping of queued SG entries

The dwc3_request->num_queued_sgs is decremented on completion. If a
partially completed request is handled, then the
dwc3_request->num_queued_sgs no longer reflects the total number of
num_queued_sgs (it would be cleared).

Correctly check the number of request SG entries remained to be prepare
and queued. Failure to do this may cause null pointer dereference when
accessing non-existent SG entry.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0247da93bf62d33304b7bf97850ebf2a86e06d28; https://git.kernel.org/stable/c/1534f6f69393aac773465d80d31801b554352627; https://git.kernel.org/stable/c/70777a23a54e359cfdfafc625a57cd56434f3859
CVE: CVE-2024-56699
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/pci: Fix potential double remove of hotplug slot

In commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the
device") the zpci_exit_slot() was moved from zpci_device_reserved() to
zpci_release_device() with the intention of keeping the hotplug slot
around until the device is actually removed.

Now zpci_release_device() is only called once all references are
dropped. Since the zPCI subsystem only drops its reference once the
device is in the reserved state it follows that zpci_release_device()
must only deal with devices in the reserved state. Despite that it
contains code to tear down from both configured and standby state. For
the standby case this already includes the removal of the hotplug slot
so would cause a double removal if a device was ever removed in
either configured or standby state.

Instead of causing a potential double removal in a case that should
never happen explicitly WARN_ON() if a device in non-reserved state is
released and get rid of the dead code cases.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/371bd905599d18da62d75e3974acbf6a41e315c7; https://git.kernel.org/stable/c/c[PII_REDACTED]ab1be46d2af1da8adb15c9fc3c069; https://git.kernel.org/stable/c/c4a585e952ca403a370586d3f16e8331a7564901
CVE: CVE-2024-56700
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

media: wl128x: Fix atomicity violation in fmc_send_cmd()

Atomicity violation occurs when the fmc_send_cmd() function is executed
simultaneously with the modification of the fmdev->resp_skb value.
Consider a scenario where, after passing the validity check within the
function, a non-null fmdev->resp_skb variable is assigned a null value.
This results in an invalid fmdev->resp_skb variable passing the validity
check. As seen in the later part of the function, skb = fmdev->resp_skb;
when the invalid fmdev->resp_skb passes the check, a null pointer
dereference error may occur at line 478, evt_hdr = (void *)skb->data;

To address this issue, it is recommended to include the validity check of
fmdev->resp_skb within the locked section of the function. This
modification ensures that the value of fmdev->resp_skb does not change
during the validation process, thereby maintaining its validity.

This possible bug is found by an experimental static analysis tool
developed by our team. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2e63c908de[PII_REDACTED]16b84740ed62dac0b269; https://git.kernel.org/stable/c/372dc9509122e5d45d4c12978e31c3c7d00aaca4; https://git.kernel.org/stable/c/378ce4e08ca2b1ac7bbf1d57b68643ca4226c5f8
CVE: CVE-2024-56701
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore

The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
the code calls kmalloc() while holding it, which can sleep:

  # echo 1 > /proc/powerpc/vcpudispatch_stats
  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
  preempt_count: 1, expected: 0
  3 locks held by sh/199:
   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
   #1: c[PII_REDACTED]c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
   #2: c[PII_REDACTED]c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
  Call Trace:
    dump_stack_lvl+0x130/0x148 (unreliable)
    __might_resched+0x174/0x410
    kmem_cache_alloc_noprof+0x340/0x3d0
    alloc_dtl_buffers+0x124/0x1ac
    vcpudispatch_stats_write+0x2a8/0x5f4
    proc_reg_write+0xf4/0x150
    vfs_write+0xfc/0x438
    ksys_write+0x88/0x148
    system_call_exception+0x1c4/0x5a0
    system_call_common+0xf4/0x258
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/525e18f1ba7c2b098c8ba587fb397efb34a6574c; https://git.kernel.org/stable/c/6956c0e7346ce1bbfc726755aa8da10d26e84276; https://git.kernel.org/stable/c/a246daa26b717e755ccc9061f47f7cd1c0b358dd
CVE: CVE-2024-56702
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Mark raw_tp arguments with PTR_MAYBE_NULL

Arguments to a raw tracepoint are tagged as trusted, which carries the
semantics that the pointer will be non-NULL.  However, in certain cases,
a raw tracepoint argument may end up being NULL. More context about this
issue is available in [0].

Thus, there is a discrepancy between the reality, that raw_tp arguments
can actually be NULL, and the verifier's knowledge, that they are never
NULL, causing explicit NULL checks to be deleted, and accesses to such
pointers potentially crashing the kernel.

To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special
case the dereference and pointer arithmetic to permit it, and allow
passing them into helpers/kfuncs; these exceptions are made for raw_tp
programs only. Ensure that we don't do this when ref_obj_id > 0, as in
that case this is an acquired object and doesn't need such adjustment.

The reason we do mask_raw_tp_trusted_reg logic is because other will
recheck in places whether the register is a trusted_reg, and then
consider our register as untrusted when detecting the presence of the
PTR_MAYBE_NULL flag.

To allow safe dereference, we enable PROBE_MEM marking when we see loads
into trusted pointers with PTR_MAYBE_NULL.

While trusted raw_tp arguments can also be passed into helpers or kfuncs
where such broken assumption may cause issues, a future patch set will
tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can
already be passed into helpers and causes similar problems. Thus, they
are left alone for now.

It is possible that these checks also permit passing non-raw_tp args
that are trusted PTR_TO_BTF_ID with null marking. In such a case,
allowing dereference when pointer is NULL expands allowed behavior, so
won't regress existing programs, and the case of passing these into
helpers is the same as above and will be dealt with later.

Also update the failure case in tp_btf_nullable selftest to capture the
new behavior, as the verifier will no longer cause an error when
directly dereference a raw tracepoint argument marked as __nullable.

  [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3634d4a310820567fc634bf8f1ee2b91378773e8; https://git.kernel.org/stable/c/c9b91d2d54175f781ad2c361cb2ac2c0e29b14b6; https://git.kernel.org/stable/c/cb4158ce8ec8a5bb528cc1693356a5eb8058094d
CVE: CVE-2024-56704
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

9p/xen: fix release of IRQ

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

[Dominique: remove confusing variable reset to 0]
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf; https://git.kernel.org/stable/c/[PII_REDACTED]b118cb8075bcee1f033b543fb719fa; https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee
CVE: CVE-2024-56705
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

media: atomisp: Add check for rgby_data memory allocation failure

In ia_css_3a_statistics_allocate(), there is no check on the allocation
result of the rgby_data memory. If rgby_data is not successfully
allocated, it may trigger the assert(host_stats->rgby_data) assertion in
ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/02a97d9d7ff605fa4a1f908d1bd3ad8573234b61; https://git.kernel.org/stable/c/0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a; https://git.kernel.org/stable/c/0c25ab93f2878cab07d37ca5afd302283201e5af
CVE: CVE-2024-56706
Published: 2024-12-28
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/cpum_sf: Fix and protect memory allocation of SDBs with mutex

Reservation of the PMU hardware is done at first event creation
and is protected by a pair of mutex_lock() and mutex_unlock().
After reservation of the PMU hardware the memory
required for the PMUs the event is to be installed on is
allocated by allocate_buffers() and alloc_sampling_buffer().
This done outside of the mutex protection.
Without mutex protection two or more concurrent invocations of
perf_event_init() may run in parallel.
This can lead to allocation of Sample Data Blocks (SDBs)
multiple times for the same PMU.
Prevent this and protect memory allocation of SDBs by
mutex.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-125, CWE-362
References: https://git.kernel.org/stable/c/4b3bdfa89635db6a53e02955548bd07bebcae233; https://git.kernel.org/stable/c/f55bd479d8663a4a4e403b3d308d3d1aa33d92df