deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-53049
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof

'modprobe slub_kunit' will have a warning as shown below. The root cause
is that __kmalloc_cache_noprof was directly used, which resulted in no
alloc_tag being allocated. This caused current->alloc_tag to be null,
leading to a warning in alloc_tag_add_check.

Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically
within lib/slub_kunit.c, which is the only user of this internal slub
function outside kmalloc implementation itself.

[58162.947016] WARNING: CPU: 2 PID: 6210 at
./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c
[58162.957721] Call trace:
[58162.957919]  alloc_tagging_slab_alloc_hook+0x268/0x27c
[58162.958286]  __kmalloc_cache_noprof+0x14c/0x344
[58162.958615]  test_kmalloc_redzone_access+0x50/0x10c [slub_kunit]
[58162.959045]  kunit_try_run_case+0x74/0x184 [kunit]
[58162.959401]  kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit]
[58162.959841]  kthread+0x10c/0x118
[58162.960093]  ret_from_fork+0x10/0x20
[58162.960363] ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b059d0d1e624adc6e69a754bc48057f8bf459dc; https://git.kernel.org/stable/c/79aea7dfd98fbbf282d1408fc21849fc9a677768
CVE: CVE-2024-53050
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in hdcp2_get_capability

Add encoder check in intel_hdcp2_get_capability to avoid
null pointer error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/5b89dcf23575eb5bb95ce8d672cbc2232c2eb096; https://git.kernel.org/stable/c/d34f4f058edf1235c103ca9c921dc54820d14d40
CVE: CVE-2024-53051
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability

Sometimes during hotplug scenario or suspend/resume scenario encoder is
not always initialized when intel_hdcp_get_capability add
a check to avoid kernel null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31b42af516afa1e184d1a9f9dd4096c54044269a; https://git.kernel.org/stable/c/4912e8fb3c37fb2dedf48d9c18bbbecd70e720f8
CVE: CVE-2024-53052
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/rw: fix missing NOWAIT check for O_DIRECT start write

When io_uring starts a write, it'll call kiocb_start_write() to bump the
super block rwsem, preventing any freezes from happening while that
write is in-flight. The freeze side will grab that rwsem for writing,
excluding any new writers from happening and waiting for existing writes
to finish. But io_uring unconditionally uses kiocb_start_write(), which
will block if someone is currently attempting to freeze the mount point.
This causes a deadlock where freeze is waiting for previous writes to
complete, but the previous writes cannot complete, as the task that is
supposed to complete them is blocked waiting on starting a new write.
This results in the following stuck trace showing that dependency with
the write blocked starting a new write:

task:fio             state:D stack:0     pid:886   tgid:886   ppid:876
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_rwsem_wait+0x1e8/0x3f8
 __percpu_down_read+0xe8/0x500
 io_write+0xbb8/0xff8
 io_issue_sqe+0x10c/0x1020
 io_submit_sqes+0x614/0x2110
 __arm64_sys_io_uring_enter+0x524/0x1038
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170
INFO: task fsfreeze:7364 blocked for more than 15 seconds.
      Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963

with the attempting freezer stuck trying to grab the rwsem:

task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_down_write+0x2b0/0x680
 freeze_super+0x248/0x8a8
 do_vfs_ioctl+0x149c/0x1b18
 __arm64_sys_ioctl+0xd0/0x1a0
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170

Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a
blocking grab of the super block rwsem if it isn't set. For normal issue
where IOCB_NOWAIT would always be set, this returns -EAGAIN which will
have io_uring core issue a blocking attempt of the write. That will in
turn also get completions run, ensuring forward progress.

Since freezing requires CAP_SYS_ADMIN in the first place, this isn't
something that can be triggered by a regular user.
CVSS Score: 4.4 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/003d2996964c03dfd[PII_REDACTED]8f4cdf1f5879e; https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389; https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929
CVE: CVE-2024-53053
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix another deadlock during RTC update

If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count
is 0, we will enter the runtime suspend callback.  However, the runtime
suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.

Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the
deadlock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/9aa1f0da237d6b16e36e0a0cc9f746d1d78396ed; https://git.kernel.org/stable/c/a128cfec44709ab1bd1f01d158569bcb2386f54f; https://git.kernel.org/stable/c/cb7e509c4e0197f63717fee54fb41c4990ba8d3a
CVE: CVE-2024-53054
Published: 2024-11-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-53055
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix 6 GHz scan construction

If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.

Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835, CWE-835
References: https://git.kernel.org/stable/c/2ac15e5a8f42fed5d90ed9e[PII_REDACTED]78c50f; https://git.kernel.org/stable/c/2ccd5badadab2d586e91546bf5af3deda07fef1f; https://git.kernel.org/stable/c/7245012f0f496162dd95d888ed2ceb5a35170f1a
CVE: CVE-2024-53056
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()

In mtk_crtc_create(), if the call to mbox_request_channel() fails then we
set the "mtk_crtc->cmdq_client.chan" pointer to NULL.  In that situation,
we do not call cmdq_pkt_create().

During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan"
is NULL first before calling cmdq_pkt_destroy().  Calling
cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and
it will result in a NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/4018651ba5c409034149f297d3dd3328b91561fd; https://git.kernel.org/stable/c/c60583a87cb4a85b69d1f448f0be5eb6ec62cbb2
CVE: CVE-2024-53057
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed
to be either root or ingress. This assumption is bogus since it's valid
to create egress qdiscs with major handle ffff:
Budimir Markovic found that for qdiscs like DRR that maintain an active
class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress
qdisc since its parent is itself. The proper fix is to stop when parent
TC_H_ROOT is reached because the only way to retrieve ingress is when a
hierarchy which does not contain a ffff: major handle call into
qdisc_lookup with TC_H_MAJ(TC_H_ROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree
levels, the updates will also propagate to TC_H_ROOT, which then the
iteration must stop.


 net/sched/sch_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/05df1b1dff8f197f1c275b57ccb2ca33021df552; https://git.kernel.org/stable/c/2e95c4384438adeaa772caa560244b1a2efef816; https://git.kernel.org/stable/c/580b3189c1972aff0f993837567d36392e9d981b
CVE: CVE-2024-53058
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data

In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.

For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
    dma_desc[N + 0],
    dma_desc[N + 1],
    dma_desc[N + 2].
Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
    tx_q->tx_skbuff_dma[N + 0],
    tx_q->tx_skbuff_dma[N + 1],
    tx_q->tx_skbuff_dma[N + 2].
Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf
is a valid buffer address.

The expected behavior that saves DMA buffer address of this non-paged
data to tx_q->tx_skbuff_dma[entry].buf is:
    tx_q->tx_skbuff_dma[N + 0].buf = NULL;
    tx_q->tx_skbuff_dma[N + 1].buf = NULL;
    tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
    tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single();
    tx_q->tx_skbuff_dma[N + 1].buf = NULL;
    tx_q->tx_skbuff_dma[N + 2].buf = NULL;

On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(

In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.

This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.

Tested and verified on DWXGMAC CORE 3.20a
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6; https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286; https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede
CVE: CVE-2024-53059
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()

1. The size of the response packet is not validated.
2. The response buffer is not freed.

Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/07a6e3b78a65f4b2796a8d0d4adb1a15a81edead; https://git.kernel.org/stable/c/3eb986c64c6bfb721950f9666a3b723cf65d043f; https://git.kernel.org/stable/c/3f45d590ccbae6dfd6faef54efe74c30bd85d3da
CVE: CVE-2024-53060
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.

Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.

Bail out also when status is AE_NOT_FOUND.

This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951:  Null pointer dereferences  (FORWARD_NULL)

(cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1a9f55ed5b512f510ccd21ad527d532e60550e80; https://git.kernel.org/stable/c/27fc29b5376998c126c85cf9b15d9dfc2afc9cbe; https://git.kernel.org/stable/c/2ac7f253deada4d449559b65a1c1cd0a6f6f19b7
CVE: CVE-2024-53061
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: s5p-jpeg: prevent buffer overflows

The current logic allows word to be less than 2. If this happens,
there will be buffer overflows, as reported by smatch. Add extra
checks to prevent it.

While here, remove an unused word = 0 assignment.
CVSS Score: 7.8 (HIGH)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/14a22762c3daeac59a5a534e124acbb4d7a79b3a; https://git.kernel.org/stable/c/784bc785a453eb2f8433dd62075befdfa1b2d6fd; https://git.kernel.org/stable/c/a930cddfd153b5d4401df0c01effa14c831ff21e
CVE: CVE-2024-53062
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mgb4: protect driver against spectre

Frequency range is set from sysfs via frequency_range_store(),
being vulnerable to spectre, as reported by smatch:

	drivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r]
	drivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half.  'reg_set'

Fix it.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/2aee207e5b3c94ef[PII_REDACTED]19ea06d6798d49; https://git.kernel.org/stable/c/e0bc90742bbd6eb9c63e6c22f8f6e10be7b1e225
CVE: CVE-2024-53063
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvbdev: prevent the risk of out of memory access

The dvbdev contains a static variable used to store dvb minors.

The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set
or not. When not set, dvb_register_device() won't check for
boundaries, as it will rely that a previous call to
dvb_register_adapter() would already be enforcing it.

On a similar way, dvb_device_open() uses the assumption
that the register functions already did the needed checks.

This can be fragile if some device ends using different
calls. This also generate warnings on static check analysers
like Coverity.

So, add explicit guards to prevent potential risk of OOM issues.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-755, CWE-755
References: https://git.kernel.org/stable/c/1e461672616b726f29261ee81bb[PII_REDACTED]37c; https://git.kernel.org/stable/c/3b88675e18b6517043a6f734eaa8ea6eb3bfa140; https://git.kernel.org/stable/c/5f76f7df14861e3a560898fa41979ec92424b58f
CVE: CVE-2024-53064
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: fix idpf_vc_core_init error path

In an event where the platform running the device control plane
is rebooted, reset is detected on the driver. It releases
all the resources and waits for the reset to complete. Once the
reset is done, it tries to build the resources back. At this
time if the device control plane is not yet started, then
the driver timeouts on the virtchnl message and retries to
establish the mailbox again.

In the retry flow, mailbox is deinitialized but the mailbox
workqueue is still alive and polling for the mailbox message.
This results in accessing the released control queue leading to
null-ptr-deref. Fix it by unrolling the work queue cancellation
and mailbox deinitialization in the reverse order which they got
initialized.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/683fcd90ba22507ebeb1921a26dfe77efff8c266; https://git.kernel.org/stable/c/9b58031ff96b84a38d7b73b23c7ecfb2e0557f43
CVE: CVE-2024-53066
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

nfs: Fix KMSAN warning in decode_getfattr_attrs()

Fix the following KMSAN warning:

CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
=====================================================
=====================================================
BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_generic+0x806/0xb00
 nfs4_xdr_dec_getattr+0x1de/0x240
 rpcauth_unwrap_resp_decode+0xab/0x100
 rpcauth_unwrap_resp+0x95/0xc0
 call_decode+0x4ff/0xb50
 __rpc_execute+0x57b/0x19d0
 rpc_execute+0x368/0x5e0
 rpc_run_task+0xcfe/0xee0
 nfs4_proc_getattr+0x5b5/0x990
 __nfs_revalidate_inode+0x477/0xd00
 nfs_access_get_cached+0x1021/0x1cc0
 nfs_do_access+0x9f/0xae0
 nfs_permission+0x1e4/0x8c0
 inode_permission+0x356/0x6c0
 link_path_walk+0x958/0x1330
 path_lookupat+0xce/0x6b0
 filename_lookup+0x23e/0x770
 vfs_statx+0xe7/0x970
 vfs_fstatat+0x1f2/0x2c0
 __se_sys_newfstatat+0x67/0x880
 __x64_sys_newfstatat+0xbd/0x120
 x64_sys_call+0x1826/0x3cf0
 do_syscall_64+0xd0/0x1b0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The KMSAN warning is triggered in decode_getfattr_attrs(), when calling
decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not
initialized.

Fix the issue by initializing fattr->mdsthreshold to NULL in
nfs_fattr_init().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/25ffd294fef81a7f3cd9528adf21560c04d98747; https://git.kernel.org/stable/c/8fc5ea9231af9122d227c9c13f5e578fca48d2e3; https://git.kernel.org/stable/c/9b453e8b108a5a93a6e348cf2ba4c9c138314a00
CVE: CVE-2024-53067
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Start the RTC update work later

The RTC update work involves runtime resuming the UFS controller. Hence,
only start the RTC update work after runtime power management in the UFS
driver has been fully initialized. This patch fixes the following kernel
crash:

Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP
Workqueue: events ufshcd_rtc_work
Call trace:
 _raw_spin_lock_irqsave+0x34/0x8c (P)
 pm_runtime_get_if_active+0x24/0x9c (L)
 pm_runtime_get_if_active+0x24/0x9c
 ufshcd_rtc_work+0x138/0x1b4
 process_one_work+0x148/0x288
 worker_thread+0x2cc/0x3d4
 kthread+0x110/0x114
 ret_from_fork+0x10/0x20
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4c25f784fba81227e0437337f962d34380d1c250; https://git.kernel.org/stable/c/54c814c8b23bc7617be3d46abdb896937695dbfa; https://git.kernel.org/stable/c/6e34b9d7caa5a4c831b74bdfed5ef86fa0c03316
CVE: CVE-2024-53069
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: qcom: scm: fix a NULL-pointer dereference

Some SCM calls can be invoked with __scm being NULL (the driver may not
have been and will not be probed as there's no SCM entry in device-tree).
Make sure we don't dereference a NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3d36e2b1d803f0d1cc674115d295a8f20ddb9268; https://git.kernel.org/stable/c/ca61d6836e6f4442a77762e1074d2706a2a6e578
CVE: CVE-2024-53070
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: fix fault at system suspend if device was already runtime suspended

If the device was already runtime suspended then during system suspend
we cannot access the device registers else it will crash.

Also we cannot access any registers after dwc3_core_exit() on some
platforms so move the dwc3_enable_susphy() call to the top.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/06b98197b69e2f2af9cb1991ee0b1c876edf7b86; https://git.kernel.org/stable/c/4abc5ee334fe4aba50461c45fdaaa4c5e5c57789; https://git.kernel.org/stable/c/562804b1561cc248cc37746a1c96c83cab1d7209
CVE: CVE-2024-53071
Published: 2024-11-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Be stricter about IO mapping flags

The current panthor_device_mmap_io() implementation has two issues:

1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,
   panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear
   VM_MAYWRITE. That means userspace can use mprotect() to make the mapping
   writable later on. This is a classic Linux driver gotcha.
   I don't think this actually has any impact in practice:
   When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and
   when the GPU is not powered, the dummy_latest_flush page provided by the
   driver is deliberately designed to not do any flushes, so the only thing
   writing to the dummy_latest_flush could achieve would be to make *more*
   flushes happen.

2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are
   mappings without the VM_SHARED flag).
   MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has
   copy-on-write semantics, which for VM_PFNMAP are semi-supported but
   fairly cursed.
   In particular, in such a mapping, the driver can only install PTEs
   during mmap() by calling remap_pfn_range() (because remap_pfn_range()
   wants to **store the physical address of the mapped physical memory into
   the vm_pgoff of the VMA**); installing PTEs later on with a fault
   handler (as panthor does) is not supported in private mappings, and so
   if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when
   it hits a BUG() check.

Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID
doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for
the FLUSH_ID don't make sense).

Reproducers for both scenarios are in the notes of my patch on the mailing
list; I tested that these bugs exist on a Rock 5B machine.

Note that I only compile-tested the patch, I haven't tested it; I don't
have a working kernel build setup for the test machine yet. Please test it
before applying it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf; https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db