deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-35790
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group

The DisplayPort driver's sysfs nodes may be present to the userspace before
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
NULL in those cases.

Remove manual sysfs node creation in favor of adding attribute group as
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
not used here otherwise the path to the sysfs nodes is no longer compliant
with the ABI.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9; https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531; https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0
CVE: CVE-2024-35791
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()

Do the cache flush of converted pages in svm_register_enc_region() before
dropping kvm->lock to fix use-after-free issues where region and/or its
array of pages could be freed by a different task, e.g. if userspace has
__unregister_enc_region_locked() already queued up for the region.

Note, the "obvious" alternative of using local variables doesn't fully
resolve the bug, as region->pages is also dynamically allocated.  I.e. the
region structure itself would be fine, but region->pages could be freed.

Flushing multiple pages under kvm->lock is unfortunate, but the entire
flow is a rare slow path, and the manual flush is only needed on CPUs that
lack coherency for encrypted memory.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4; https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d; https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865
CVE: CVE-2024-35792
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: rk3288 - Fix use after free in unprepare

The unprepare call must be carried out before the finalize call
as the latter can free the request.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/48dd260fdb728eda4a246f635d1325e82f0d3555; https://git.kernel.org/stable/c/c0afb6b88fbbc177fa322a835f874be217bffe45; https://git.kernel.org/stable/c/eb2a41a8ae8c8c4f68aef3bd94665c0cf23e04be
CVE: CVE-2024-35793
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

debugfs: fix wait/cancellation handling during remove

Ben Greear further reports deadlocks during concurrent debugfs
remove while files are being accessed, even though the code in
question now uses debugfs cancellations. Turns out that despite
all the review on the locking, we missed completely that the
logic is wrong: if the refcount hits zero we can finish (and
need not wait for the completion), but if it doesn't we have
to trigger all the cancellations. As written, we can _never_
get into the loop triggering the cancellations. Fix this, and
explain it better while at it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3d08cca5fd0aabb62b7015067ab40913b33da906; https://git.kernel.org/stable/c/952c3fce297f12c7ff59380adb66b564e2bc9b64; https://git.kernel.org/stable/c/e88b5ae01901c4a655a[PII_REDACTED]6334778a57b
CVE: CVE-2024-35794
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

dm-raid: really frozen sync_thread during suspend

1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove
   MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that
   dm-raid relies on __md_stop_writes() to frozen sync_thread
   indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in
   md_stop_writes(), and since stop_sync_thread() is only used for
   dm-raid in this case, also move stop_sync_thread() to
   md_stop_writes().
2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen,
   it only prevent new sync_thread to start, and it can't stop the
   running sync thread; In order to frozen sync_thread, after seting the
   flag, stop_sync_thread() should be used.
3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use
   it as condition for md_stop_writes() in raid_postsuspend() doesn't
   look correct. Consider that reentrant stop_sync_thread() do nothing,
   always call md_stop_writes() in raid_postsuspend().
4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime,
   and if MD_RECOVERY_FROZEN is cleared while the array is suspended,
   new sync_thread can start unexpected. Fix this by disallow
   raid_message() to change sync_thread status during suspend.

Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the
test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),
and with previous fixes, the test won't hang there anymore, however, the
test will still fail and complain that ext4 is corrupted. And with this
patch, the test won't hang due to stop_sync_thread() or fail due to ext4
is corrupted anymore. However, there is still a deadlock related to
dm-raid456 that will be fixed in following patches.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/16c4770c75b1223998adbeb7286f9a15c65fba73; https://git.kernel.org/stable/c/af916cb66a80597f3523bc85812e790bcdcfd62b; https://git.kernel.org/stable/c/eaa8fc9b092837cf2c754bde1a15d784ce9a85ab
CVE: CVE-2024-5045
Published: 2024-05-17
Description: A vulnerability was found in SourceCodester Online Birth Certificate Management System 1.0. It has been declared as problematic. This vulnerability affects unknown code of the file /admin. The manipulation leads to files or directories accessible. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-264742 is the identifier assigned to this vulnerability.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-552
References: https://github.com/HuoMingZ/aoligei/blob/main/yuzu.md; https://vuldb.com/?ctiid.264742; https://vuldb.com/?id.264742
CVE: CVE-2024-5046
Published: 2024-05-17
Description: A vulnerability was found in SourceCodester Online Examination System 1.0. It has been rated as critical. This issue affects some unknown processing of the file registeracc.php. The manipulation of the argument email leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-264743.
CVSS Score: 7.3 (HIGH)
CWE: CWE-89
References: https://github.com/CveSecLook/cve/issues/32; https://vuldb.com/?ctiid.264743; https://vuldb.com/?id.264743
CVE: CVE-2023-52661
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe()

If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be
undone.

Add the missing clk_put and a new 'put_pll_d_out0' label in the error
handling path, and use it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7; https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3; https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0
CVE: CVE-2023-52662
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node

When ida_alloc_max fails, resources allocated before should be freed,
including *res allocated by kmalloc and ttm_resource_init.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf; https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a; https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6
CVE: CVE-2023-52663
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()

Driver uses kasprintf() to initialize fw_{code,data}_bin members of
struct acp_dev_data, but kfree() is never called to deallocate the
memory, which results in a memory leak.

Fix the issue by switching to devm_kasprintf(). Additionally, ensure the
allocation was successful by checking the pointer validity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/222be59e5eed[PII_REDACTED]edc743ee548c2371d0; https://git.kernel.org/stable/c/7296152e58858f928db448826eb7ba5ae611297b; https://git.kernel.org/stable/c/88028c45d5871dfc449b2b0a27abf6428453a5ec
CVE: CVE-2023-52664
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: eliminate double free in error handling logic

Driver has a logic leak in ring data allocation/free,
where aq_ring_free could be called multiple times on same ring,
if system is under stress and got memory allocation error.

Ring pointer was used as an indicator of failure, but this is
not correct since only ring data is allocated/deallocated.
Ring itself is an array member.

Changing ring allocation functions to return error code directly.
This simplifies error handling and eliminates aq_ring_free
on higher layer.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d; https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928; https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
CVE: CVE-2023-52665
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-52666
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-52667
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: fix a potential double-free in fs_any_create_groups

When kcalloc() for ft->g succeeds but kvzalloc() for in fails,
fs_any_create_groups() will free ft->g. However, its caller
fs_any_create_table() will free ft->g again through calling
mlx5e_destroy_flow_table(), which will lead to a double-free.
Fix this by setting ft->g to NULL in fs_any_create_groups().
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/2897c981ee63e1be5e530b[PII_REDACTED]a10b26d8; https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779; https://git.kernel.org/stable/c/72a[PII_REDACTED]52b5a294d27453da264106983b1
CVE: CVE-2023-52668
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: fix lock ordering in btrfs_zone_activate()

The btrfs CI reported a lockdep warning as follows by running generic
generic/129.

   WARNING: possible circular locking dependency detected
   6.7.0-rc5+ #1 Not tainted
   ------------------------------------------------------
   kworker/u5:5/793427 is trying to acquire lock:
   ffff88813256d028 (&cache->lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x5e/0x130
   but task is already holding lock:
   ffff88810a23a318 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x34/0x130
   which lock already depends on the new lock.

   the existing dependency chain (in reverse order) is:
   -> #1 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}:
   ...
   -> #0 (&cache->lock){+.+.}-{2:2}:
   ...

This is because we take fs_info->zone_active_bgs_lock after a block_group's
lock in btrfs_zone_activate() while doing the opposite in other places.

Fix the issue by expanding the fs_info->zone_active_bgs_lock's critical
section and taking it before a block_group's lock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1908e9d01e5395adff68d9d308a0fb15337e6272; https://git.kernel.org/stable/c/6f74989f5909cdec9b1274641f0fa306b15bb476; https://git.kernel.org/stable/c/b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3
CVE: CVE-2023-52669
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: s390/aes - Fix buffer overread in CTR mode

When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left.  Fix
this by using the actual length left and copy it into a buffer first
for processing.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a[PII_REDACTED]5; https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79; https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
CVE: CVE-2023-52670
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

rpmsg: virtio: Free driver_override when rpmsg_remove()

Free driver_override when rpmsg_remove(), otherwise
the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128):
  comm "kworker/u8:2", pid 56, jiffies[PII_REDACTED] (age 214.272s)
  hex dump (first 32 bytes):
    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
    [<[PII_REDACTED]00d89b>] __kmalloc_node_track_caller+0x44/0x70
    [<[PII_REDACTED]8a60c3>] kstrndup+0x4c/0x90
    [<[PII_REDACTED]>] driver_set_override+0xd0/0x164
    [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
    [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
    [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
    [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
    [<[PII_REDACTED]3331cc>] really_probe+0xbc/0x2dc
    [<[PII_REDACTED]1064b1>] __driver_probe_device+0x78/0xe0
    [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
    [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
    [<[PII_REDACTED]cd7614>] bus_for_each_drv+0x7c/0xd4
    [<000000003b929a36>] __device_attach+0x9c/0x19c
    [<00000000a94e0ba8>] device_initial_probe+0x14/0x20
    [<000000003c999637>] bus_probe_device+0xa0/0xac
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08; https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6; https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
CVE: CVE-2023-52671
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix hang/underflow when transitioning to ODM4:1

[Why]
Under some circumstances, disabling an OPTC and attempting to reclaim
its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs
not being properly disconnected from the disabled OPTC.

[How]
Ensure that all OPPs are unassigned from an OPTC when it gets disabled.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b6b479b2da6badff099b2e3abf0248936eefbf5; https://git.kernel.org/stable/c/ae62f1dde66a6f0eee98defc4c7a346bd5acd239; https://git.kernel.org/stable/c/e7b2b108cdeab76a7e7324459e50b0c1214c0386
CVE: CVE-2023-52672
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

pipe: wakeup wr_wait after setting max_usage

Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].

The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.

Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.

[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-400
References: https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8; https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9; https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
CVE: CVE-2023-52673
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix a debugfs null pointer error

[WHY & HOW]
Check whether get_subvp_en() callback exists before calling it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/43235db21fc23559f50a62f8f273002eeb506f5a; https://git.kernel.org/stable/c/efb91fea652a42fcc037d2a9ef4ecd1ffc5ff4b7; https://git.kernel.org/stable/c/43235db21fc23559f50a62f8f273002eeb506f5a
CVE: CVE-2024-34919
Published: 2024-05-17
Description: An arbitrary file upload vulnerability in the component \modstudent\controller.php of Pisay Online E-Learning System using PHP/MySQL v1.0 allows attackers to execute arbitrary code via uploading a crafted file.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-74
References: https://github.com/CveSecLook/cve/issues/20; https://github.com/CveSecLook/cve/issues/20
CVE: CVE-2024-34982
Published: 2024-05-17
Description: An arbitrary file upload vulnerability in the component /include/file.php of lylme_spage v1.9.5 allows attackers to execute arbitrary code via uploading a crafted file.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-434
References: https://github.com/n2ryx/CVE/blob/main/Lylme_pagev1.9.5.md; https://github.com/n2ryx/CVE/blob/main/Lylme_pagev1.9.5.md
CVE: CVE-2024-35796
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ll_temac: platform_get_resource replaced by wrong function

The function platform_get_resource was replaced with
devm_platform_ioremap_resource_byname and is called using 0 as name.

This eventually ends up in platform_get_resource_byname in the call
stack, where it causes a null pointer in strcmp.

	if (type == resource_type(r) && !strcmp(r->name, name))

It should have been replaced with devm_platform_ioremap_resource.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11; https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3; https://git.kernel.org/stable/c/476eed5f1c[PII_REDACTED]2a980aa48dc4662cb39a
CVE: CVE-2024-35797
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: cachestat: fix two shmem bugs

When cachestat on shmem races with swapping and invalidation, there
are two possible bugs:

1) A swapin error can have resulted in a poisoned swap entry in the
   shmem inode's xarray. Calling get_shadow_from_swap_cache() on it
   will result in an out-of-bounds access to swapper_spaces[].

   Validate the entry with non_swap_entry() before going further.

2) When we find a valid swap entry in the shmem's inode, the shadow
   entry in the swapcache might not exist yet: swap IO is still in
   progress and we're before __remove_mapping; swapin, invalidation,
   or swapoff have removed the shadow from swapcache after we saw the
   shmem swap entry.

   This will send a NULL to workingset_test_recent(). The latter
   purely operates on pointer bits, so it won't crash - node 0, memcg
   ID 0, eviction timestamp 0, etc. are all valid inputs - but it's a
   bogus test. In theory that could result in a false "recently
   evicted" count.

   Such a false positive wouldn't be the end of the world. But for
   code clarity and (future) robustness, be explicit about this case.

   Bail on get_shadow_from_swap_cache() returning NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/24a0e73d544439bb9329fbbafac44299e548a677; https://git.kernel.org/stable/c/b79f9e1ff27c994a4c452235ba09e672ec698e23; https://git.kernel.org/stable/c/d5d39c707a4cf0bcc[PII_REDACTED]7b97aa2cb2627
CVE: CVE-2024-35798
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix race in read_extent_buffer_pages()

There are reports from tree-checker that detects corrupted nodes,
without any obvious pattern so possibly an overwrite in memory.
After some debugging it turns out there's a race when reading an extent
buffer the uptodate status can be missed.

To prevent concurrent reads for the same extent buffer,
read_extent_buffer_pages() performs these checks:

    /* (1) */
    if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))
        return 0;

    /* (2) */
    if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))
        goto done;

At this point, it seems safe to start the actual read operation. Once
that completes, end_bbio_meta_read() does

    /* (3) */
    set_extent_buffer_uptodate(eb);

    /* (4) */
    clear_bit(EXTENT_BUFFER_READING, &eb->bflags);

Normally, this is enough to ensure only one read happens, and all other
callers wait for it to finish before returning.  Unfortunately, there is
a racey interleaving:

    Thread A | Thread B | Thread C
    ---------+----------+---------
       (1)   |          |
             |    (1)   |
       (2)   |          |
       (3)   |          |
       (4)   |          |
             |    (2)   |
             |          |    (1)

When this happens, thread B kicks of an unnecessary read. Worse, thread
C will see UPTODATE set and return immediately, while the read from
thread B is still in progress.  This race could result in tree-checker
errors like this as the extent buffer is concurrently modified:

    BTRFS critical (device dm-0): corrupted node, root=256
    block=[PII_REDACTED]682405139 owner mismatch, have[PII_REDACTED][PII_REDACTED]
    expect [256,[PII_REDACTED][PII_REDACTED]]

Fix it by testing UPTODATE again after setting the READING bit, and if
it's been set, skip the unnecessary read.

[ minor update of changelog ]
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052; https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1; https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80
CVE: CVE-2024-35799
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Prevent crash when disable stream

[Why]
Disabling stream encoder invokes a function that no longer exists.

[How]
Check if the function declaration is NULL in disable stream encoder.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-400
References: https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48; https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06; https://git.kernel.org/stable/c/59772327d[PII_REDACTED]16673b4b30c48bd83ca38
CVE: CVE-2024-35800
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

efi: fix panic in kdump kernel

Check if get_next_variable() is actually valid pointer before
calling it. In kdump kernel this method is set to NULL that causes
panic during the kexec-ed kernel boot.

Tested with QEMU and OVMF firmware.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc[PII_REDACTED]978210; https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531; https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff