deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-46829
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

rtmutex: Drop rt_mutex::wait_lock before scheduling

rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the
good case it returns with the lock held and in the deadlock case it emits a
warning and goes into an endless scheduling loop with the lock held, which
triggers the 'scheduling in atomic' warning.

Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning
and dropping into the schedule for ever loop.

[ tglx: Moved unlock before the WARN(), removed the pointless comment,
  	massaged changelog, added Fixes tag ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0; https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38; https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f
CVE: CVE-2024-46830
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS

Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
reads guest memory.

Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
via sync_regs(), which already holds SRCU.  I.e. trying to precisely use
kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
problems.  Acquiring SRCU isn't all that expensive, so for simplicity,
grab it unconditionally for KVM_SET_VCPU_EVENTS.

 =============================
 WARNING: suspicious RCU usage
 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
 -----------------------------
 include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by repro/1071:
  #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]

 stack backtrace:
 CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Call Trace:
  <TASK>
  dump_stack_lvl+0x7f/0x90
  lockdep_rcu_suspicious+0x13f/0x1a0
  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
  kvm_vcpu_read_guest+0x3e/0x90 [kvm]
  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
  vmx_leave_nested+0x30/0x40 [kvm_intel]
  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
  ? mark_held_locks+0x49/0x70
  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]
  kvm_vcpu_ioctl+0x497/0x970 [kvm]
  ? lock_acquire+0xba/0x2d0
  ? find_held_lock+0x2b/0x80
  ? do_user_addr_fault+0x40c/0x6f0
  ? lock_release+0xb7/0x270
  __x64_sys_ioctl+0x82/0xb0
  do_syscall_64+0x6c/0x170
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7ff11eb1b539
  </TASK>
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/4bcdd831d9d01e0fb64faea50732b59b2ee88da1; https://git.kernel.org/stable/c/5f35099fa3d59caf10bda88b033538e90086684e; https://git.kernel.org/stable/c/939375737b5a0b1bf9b1e75129054e11bc9ca65e
CVE: CVE-2024-46831
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: microchip: vcap: Fix use-after-free error in kunit test

This is a clear use-after-free error. We remove it, and rely on checking
the return code of vcap_del_rule.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/a3c1e45156ad39f225cd7ddae0f81230a3b1e657; https://git.kernel.org/stable/c/b0804c286ccfcf5f5c004d5bf8a54c0508b5e86b; https://git.kernel.org/stable/c/f7fe95f40c85311c98913fe6ae2c56adb7f767a7
CVE: CVE-2024-46832
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed

This avoids warning:

[    0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283

Caused by get_c0_compare_int on secondary CPU.

We also skipped saving IRQ number to struct clock_event_device *cd as
it's never used by clockevent core, as per comments it's only meant
for "non CPU local devices".
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52; https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30; https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13
CVE: CVE-2024-46833
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: void array out of bound when loop tnl_num

When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes
from hardware and the length of array is a fixed value. To void array out
of bound, make sure the loop time is not greater than the length of array
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/86db7bfb06704ef17340eeae71c832f21cfce35c; https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb[PII_REDACTED]1ad4
CVE: CVE-2024-46834
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036; https://git.kernel.org/stable/c/2899d58462ba868287d6ff3acad3675e7adf934f
CVE: CVE-2024-46835
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix smatch static checker warning

adev->gfx.imu.funcs could be NULL
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a; https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027; https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0
CVE: CVE-2024-46836
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: aspeed_udc: validate endpoint index for ast udc

We should verify the bound of the array to assure that host
may not manipulate the index to point past endpoint array.

Found by static analysis.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/31bd4fab49c0adc[PII_REDACTED]c1b1df9395858af; https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c[PII_REDACTED]e8a; https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c
CVE: CVE-2024-46837
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Restrict high priorities on group_create

We were allowing any users to create a high priority group without any
permission checks. As a result, this was allowing possible denial of
service.

We now only allow the DRM master or users with the CAP_SYS_NICE
capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM.

As the sole user of that uAPI lives in Mesa and hardcode a value of
MEDIUM [1], this should be safe to do.

Additionally, as those checks are performed at the ioctl level,
panthor_group_create now only check for priority level validity.

[1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/33eb0344e186a2bcc257c6c5a6e65c1cb42adb4a; https://git.kernel.org/stable/c/5f7762042f8a5377bd8a32844db353c0311a7369
CVE: CVE-2024-46838
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: don't BUG_ON() if khugepaged yanks our page table

Since khugepaged was changed to allow retracting page tables in file
mappings without holding the mmap lock, these BUG_ON()s are wrong - get
rid of them.

We could also remove the preceding "if (unlikely(...))" block, but then we
could reach pte_offset_map_lock() with transhuge pages not just for file
mappings but also for anonymous mappings - which would probably be fine
but I think is not necessarily expected.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4828d207dc5161dc7ddf9a4f6dcfd80c7dd7d20a; https://git.kernel.org/stable/c/4a594acc12d5954cdc71d4450a386748bf3d136a; https://git.kernel.org/stable/c/db978287e908d48b209e374b00d847b2d785e0a9
CVE: CVE-2024-46839
Published: 2024-09-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-46840
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption.  Change that to return
-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling.  Also adjust the error message so we can
actually do something with the information.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16; https://git.kernel.org/stable/c/71291aa7246645ef622621934d[PII_REDACTED]645e; https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32
CVE: CVE-2024-46841
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()

We handle errors here properly, ENOMEM isn't fatal, return the error.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/135b4819f6fba87fd5a[PII_REDACTED]e78ac73f1d3; https://git.kernel.org/stable/c/44a2c518ab221c0cadcb8c45ca86f83a52dd4da6; https://git.kernel.org/stable/c/6a0648f96c3ca647c71c6c1ddbc7c353bab79f64
CVE: CVE-2024-46842
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info

The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the
routine unconditionally frees submitted mailbox commands regardless of
return status.  The issue is that for MBX_TIMEOUT cases, when firmware
returns SFP information at a later time, that same mailbox memory region
references previously freed memory in its cmpl routine.

Fix by adding checks for the MBX_TIMEOUT return code.  During mailbox
resource cleanup, check the mbox flag to make sure that the wait did not
timeout.  If the MBOX_WAKE flag is not set, then do not free the resources
because it will be freed when firmware completes the mailbox at a later
time in its cmpl routine.

Also, increase the timeout from 30 to 60 seconds to accommodate boot
scripts requiring longer timeouts.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58; https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48
CVE: CVE-2024-46843
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Remove SCSI host only if added

If host tries to remove ufshcd driver from a UFS device it would cause a
kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before
adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host
has been defered after MCQ configuration introduced by commit 0cab4023ec7b
("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").

To guarantee that SCSI host is removed only if it has been added, set the
scsi_host_added flag to true after adding a SCSI host and check whether it
is set or not before removing it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed; https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536; https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc
CVE: CVE-2024-46844
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

um: line: always fill *error_out in setup_one_line()

The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line().
CVSS Score: 7.8 (HIGH)
CWE: CWE-824
References: https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf; https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5; https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6
CVE: CVE-2024-46845
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/timerlat: Only clear timer if a kthread exists

The timerlat tracer can use user space threads to check for osnoise and
timer latency. If the program using this is killed via a SIGTERM, the
threads are shutdown one at a time and another tracing instance can start
up resetting the threads before they are fully closed. That causes the
hrtimer assigned to the kthread to be shutdown and freed twice when the
dying thread finally closes the file descriptors, causing a use-after-free
bug.

Only cancel the hrtimer if the associated thread is still around. Also add
the interface_lock around the resetting of the tlat_var->kthread.

Note, this is just a quick fix that can be backported to stable. A real
fix is to have a better synchronization between the shutdown of old
threads and the starting of new ones.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/8a9d0d405159e9c796ddf771f7cff691c1a2bc1e; https://git.kernel.org/stable/c/8c72f0b2c45f21cb8b00fc37f79f632d7e46c2ed; https://git.kernel.org/stable/c/e6a53481da292d970d1edf0d8831121d1c5e2f0d
CVE: CVE-2024-46846
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: rockchip: Resolve unbalanced runtime PM / system PM handling

Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.

Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.

Also, refactor some of the resume() error handling, because it's not
actually a good idea to re-disable clocks on failure.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0efbad8445fbba[PII_REDACTED]a1473450a299a08a; https://git.kernel.org/stable/c/14f970a8d03d882b15b97beb83bd84ac8ba6298c; https://git.kernel.org/stable/c/be721b451affbecc4ba4eaac3b71cdbdcade1b1b
CVE: CVE-2024-46847
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: vmalloc: ensure vmap_block is initialised before adding to queue

Commit 8c61291fd850 ("mm: fix incorrect vbq reference in
purge_fragmented_block") extended the 'vmap_block' structure to contain a
'cpu' field which is set at allocation time to the id of the initialising
CPU.

When a new 'vmap_block' is being instantiated by new_vmap_block(), the
partially initialised structure is added to the local 'vmap_block_queue'
xarray before the 'cpu' field has been initialised.  If another CPU is
concurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it
may perform an out-of-bounds access to the remote queue thanks to an
uninitialised index.

This has been observed as UBSAN errors in Android:

 | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
 |
 | Call trace:
 |  purge_fragmented_block+0x204/0x21c
 |  _vm_unmap_aliases+0x170/0x378
 |  vm_unmap_aliases+0x1c/0x28
 |  change_memory_common+0x1dc/0x26c
 |  set_memory_ro+0x18/0x24
 |  module_enable_ro+0x98/0x238
 |  do_init_module+0x1b0/0x310

Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the
addition to the xarray.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1b2770e27d6d952f491bb362b657e5b2713c3efd; https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255; https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671
CVE: CVE-2024-46848
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following
warnings.

perfevents: irq loop stuck!
  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
  intel_pmu_handle_irq+0x285/0x370
  Call Trace:
   <NMI>
   ? __warn+0xa4/0x220
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? report_bug+0x3e/0xa0
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x50
   ? asm_exc_invalid_op+0x1a/0x20
   ? irq_work_claim+0x1e/0x40
   ? intel_pmu_handle_irq+0x285/0x370
   perf_event_nmi_handler+0x3d/0x60
   nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period < 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d; https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468; https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b
CVE: CVE-2024-46849
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: meson: axg-card: fix 'use-after-free'

Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()',
so move 'pad' pointer initialization after this function when memory is
already reallocated.

Kasan bug report:

==================================================================
BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc
Read of size 8 at addr ffff000000e8b260 by task modprobe/356

CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1
Call trace:
 dump_backtrace+0x94/0xec
 show_stack+0x18/0x24
 dump_stack_lvl+0x78/0x90
 print_report+0xfc/0x5c0
 kasan_report+0xb8/0xfc
 __asan_load8+0x9c/0xb8
 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]
 meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]
 platform_probe+0x8c/0xf4
 really_probe+0x110/0x39c
 __driver_probe_device+0xb8/0x18c
 driver_probe_device+0x108/0x1d8
 __driver_attach+0xd0/0x25c
 bus_for_each_dev+0xe0/0x154
 driver_attach+0x34/0x44
 bus_add_driver+0x134/0x294
 driver_register+0xa8/0x1e8
 __platform_driver_register+0x44/0x54
 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]
 do_one_initcall+0xdc/0x25c
 do_init_module+0x10c/0x334
 load_module+0x24c4/0x26cc
 init_module_from_file+0xd4/0x128
 __arm64_sys_finit_module+0x1f4/0x41c
 invoke_syscall+0x60/0x188
 el0_svc_common.constprop.0+0x78/0x13c
 do_el0_svc+0x30/0x40
 el0_svc+0x38/0x78
 el0t_64_sync_handler+0x100/0x12c
 el0t_64_sync+0x190/0x194
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4f9a71435953f941969a4f017e2357db62d85a86; https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc[PII_REDACTED]7eb04d61dc3d; https://git.kernel.org/stable/c/7d318166bf55e9029d56997c3b134f4ac2ae2607
CVE: CVE-2024-46850
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()

dc_state_destruct() nulls the resource context of the DC state. The pipe
context passed to dcn35_set_drr() is a member of this resource context.

If dc_state_destruct() is called parallel to the IRQ processing (which
calls dcn35_set_drr() at some point), we can end up using already nulled
function callback fields of struct stream_resource.

The logic in dcn35_set_drr() already tries to avoid this, by checking tg
against NULL. But if the nulling happens exactly after the NULL check and
before the next access, then we get a race.

Avoid this by copying tg first to a local variable, and then use this
variable for all the operations. This should work, as long as nobody
frees the resource pool where the timing generators live.

(cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5)
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]6a540428e58d370b3c1599a617bac7; https://git.kernel.org/stable/c/e835d5144f5ef78e4f8828c63e2f0d61144f283a
CVE: CVE-2024-46851
Published: 2024-09-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()

dc_state_destruct() nulls the resource context of the DC state. The pipe
context passed to dcn10_set_drr() is a member of this resource context.

If dc_state_destruct() is called parallel to the IRQ processing (which
calls dcn10_set_drr() at some point), we can end up using already nulled
function callback fields of struct stream_resource.

The logic in dcn10_set_drr() already tries to avoid this, by checking tg
against NULL. But if the nulling happens exactly after the NULL check and
before the next access, then we get a race.

Avoid this by copying tg first to a local variable, and then use this
variable for all the operations. This should work, as long as nobody
frees the resource pool where the timing generators live.

(cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643)
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/a7aeb03888b92304e2fc7d4d1c242f54a312561b; https://git.kernel.org/stable/c/b6ce047a81f508f5c60756db8dfb5ff486e4dad0