huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-56693: kernel: brd: defer automatic disk creation until module initialization succeeds
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-12-28T00:00:00+00:00

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.


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.174, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 41219c147df8bbd6591f59af5d695fb6c9a1cbff
CVE-2024-56709: kernel: io_uring: check if iowq is killed before queuing
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-29T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

io_uring: check if iowq is killed before queuing

task work can be executed after the task has gone through io_uring
termination, whether it's the final task_work run or the fallback path.
In this case, task work will find ->io_wq being already killed and
null'ed, which is a problem if it then tries to forward the request to
io_queue_iowq(). Make io_queue_iowq() fail requests in this case.

Note that it also checks PF_KTHREAD, because the user can first close
a DEFER_TASKRUN ring and shortly after kill the task, in which case
->iowq check would race.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Affected upstream versions: 5.14
Fixed upstream versions: 0, 6.1.122, 6.12.7, 6.13, 6.6.68
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 534d59ab38010aada88390db65985e65d0de7d9e
CVE-2024-56721: kernel: x86/CPU/AMD: Terminate the erratum_1386_microcode array
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-12-29T00:00:00+00:00

A flaw was found in the AMD CPU erratum handling code in the Linux kernel. The erratum_1386_microcode array lacked a proper terminator, which could cause the x86_match_cpu_with_stepping() function to read beyond the end of the array. This results in undefined behavior during CPU feature detection and erratum handling. A local attacker may be able to exploit this flaw to cause a system crash or instability, affecting system availability.

Statement: A potential out-of-bounds read was found in the Linux kernel's AMD CPU erratum handling logic. The erratum_1386_microcode array lacked a terminating empty entry, which could cause x86_match_cpu_with_stepping() to iterate beyond the array bounds. This might lead to incorrect behavior or kernel instability depending on memory layout at runtime.
The vulnerable code is part of the AMD erratum workaround logic in the CPU initialization path. Triggering this condition requires privileged kernel access, such as during CPU bring-up or microcode handling, which are not accessible to unprivileged users. Therefore, Privileges Required is set to High (PR:H).

Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.11.11, 6.12.2, 6.13
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 82d6b82cf89d950982ac240ba068c3a7e1f23b0a
CVE-2024-56729: kernel: smb: Initialize cfid->tcon before performing network ops
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-29T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

smb: Initialize cfid->tcon before performing network ops

Avoid leaking a tcon ref when a lease break races with opening the
cached directory. Processing the leak break might take a reference to
the tcon in cached_dir_lease_break() and then fail to release the ref in
cached_dir_offload_close, since cfid->tcon is still NULL.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 625e2357c8fcfae6e66dcc667dc656fe390bab15
CVE-2024-56739: kernel: rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-29T00:00:00+00:00

A vulnerability was found in the Linux kernel's RTC driver in the rtc_timer_do_work() function, where the __rtc_read_time call may fail. This issue results in uninitialized data in the rtc_time struct. It can lead to the generation of extremely large values, causing periodic timer failures and potentially triggering a kernel softlockup, impacting system stability.


Affected upstream versions: 2.6.38
Fixed upstream versions: 0, 4.19.325, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f
CVE-2024-56757: kernel: Bluetooth: btusb: mediatek: add intf release flow when usb disconnect
Component: kernel
Severity: Moderate
CWE: CWE-404 (Improper Resource Shutdown or Release)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-06T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: mediatek: add intf release flow when usb disconnect

MediaTek claim an special usb intr interface for ISO data transmission.
The interface need to be released before unregistering hci device when
usb disconnect. Removing BT usb dongle without properly releasing the
interface may cause Kernel panic while unregister hci device.


Affected upstream versions: 6.11
Fixed upstream versions: 0, 6.12.8, 6.13
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cc569d791ab2a0de74f76e470515d25d24c9b84b
CVE-2024-56760: kernel: PCI/MSI: Handle lack of irqdomain gracefully
Component: kernel
Severity: Moderate
CWE: CWE-754 (Improper Check for Unusual or Exceptional Conditions)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-06T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
RISCV platform which does not provide PCI/MSI support:

 WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
 __pci_enable_msix_range+0x30c/0x596
 pci_msi_setup_msi_irqs+0x2c/0x32
 pci_alloc_irq_vectors_affinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement
the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
domain is associated with the device or not. There is a check for MSI-X,
which has a legacy assumption. But that legacy fallback assumption is only
valid when legacy support is enabled, but otherwise the check should simply
return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support
without implementing the legacy fallbacks. There are weak implementations
which return an error, so the problem was papered over.

Correct pci_msi_domain_supports() to evaluate the legacy mode and add
the missing supported check into the MSI enable path to complete it.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.12.8, 6.13, 6.6.69
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b1f7476e07b93d65a1a3643dcb4a7bed80d4328d
CVE-2024-56783: kernel: netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
Component: kernel
Severity: Moderate
CWE: CWE-617 (Reachable Assertion)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level

cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to
restrict this maximum depth to a more reasonable value not to harm
performance. Remove unnecessary WARN_ON_ONCE which is reachable from
userspace.


Affected upstream versions: 6.1.112 < 6.1.120, 6.6.53 < 6.6.66, 6.10.12 < 6.11, 6.11
Fixed upstream versions: 0, 6.1.120, 6.11, 6.12.5, 6.13, 6.6.66
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7064a6daa4a700a298fe3aee11dea296bfe59fc4
CVE-2024-56826: openjpeg: heap buffer overflow in bin/common/color.c
Component: openjpeg
Severity: Moderate
CWE: CWE-122 (Heap-based Buffer Overflow)
CVSS v3: 5.6 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H)
Public date: 2024-12-24T00:00:00+00:00

A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.


Affected upstream versions: <= v2.5.2
Fixed upstream versions: 0:2.4.0-8.el9, 2.5.3
Upstream repository: https://github.com/uclouvain/openjpeg
Upstream fix commit: e492644fbded4c820ca55b5e50e598d346e850e8
CVE-2024-56827: openjpeg: heap buffer overflow in lib/openjp2/j2k.c
Component: openjpeg
Severity: Moderate
CWE: CWE-122 (Heap-based Buffer Overflow)
CVSS v3: 5.6 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H)
Public date: 2024-12-24T00:00:00+00:00

A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.


Affected upstream versions: <= v2.5.2
Fixed upstream versions: 0:2.4.0-8.el9, 2.5.3
Upstream repository: https://github.com/uclouvain/openjpeg
Upstream fix commit: e492644fbded4c820ca55b5e50e598d346e850e8
CVE-2024-57798: kernel: drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()

While receiving an MST up request message from one thread in
drm_dp_mst_handle_up_req(), the MST topology could be removed from
another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.
This could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req().

Avoid the above by holding a reference for mst_primary in
drm_dp_mst_handle_up_req() while it's used.

v2: Fix kfreeing the request if getting an mst_primary reference fails.

Statement: This issue is considered to be a moderate impact flaw, as the exploitation for this will need an ADMIN (or ROOT) privilege (PR:H).

Affected upstream versions: 5.5
Fixed upstream versions: 0, 6.1.123, 6.12.8, 6.13, 6.6.69
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f61b2e5e7821f868d6afc22382a66a30ee780ba0
CVE-2024-57807: kernel: scsi: megaraid_sas: Fix for a potential deadlock
Component: kernel
Severity: Low
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

scsi: megaraid_sas: Fix for a potential deadlock

This fixes a 'possible circular locking dependency detected' warning
      CPU0                    CPU1
      ----                    ----
 lock(&instance->reset_mutex);
                              lock(&shost->scan_mutex);
                              lock(&instance->reset_mutex);
 lock(&shost->scan_mutex);

Fix this by temporarily releasing the reset_mutex.


Affected upstream versions: 5.4.134 < 5.4.289, 5.10.52 < 5.10.233, 5.12.19 < 5.13, 5.13.4 < 5.14, 5.14
Fixed upstream versions: 0, 5.10.233, 5.13, 5.14, 5.15.176, 5.4.289, 6.1.123, 6.12.8, 6.13, 6.6.69
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 78afb9bfad00c4aa58a424111d7edbcab9452f2b
CVE-2024-57809: kernel: PCI: imx6: Fix suspend/resume support on i.MX6QDL
Component: kernel
Severity: Moderate
CWE: CWE-248 (Uncaught Exception)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-11T00:00:00+00:00

A flaw was found in the PCI-imx6 module in the Linux kernel. The suspend/resume support is missing in the i.MX6QDL platforms, allowing certain drivers, such as ath10k and iwlwifi, to crash after resuming, causing a kernel hang and a denial of service.

Statement: The PCI-imx6 module in the Linux kernel as shipped in Red Hat Enterprise Linux 8 is not affected by this vulnerability because the vulnerable code was introduced in a newer version of the Linux kernel.

Affected upstream versions: 4.20
Fixed upstream versions: 0, 6.12.4, 6.13
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ac43ea3d27a8f9beadf3af66c9ea4a566ebfff1f
CVE-2024-57843: kernel: virtio-net: fix overflow inside virtnet_rq_alloc
Component: kernel
Severity: Moderate
CWE: CWE-131 (Incorrect Calculation of Buffer Size)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

virtio-net: fix overflow inside virtnet_rq_alloc

When the frag just got a page, then may lead to regression on VM.
Specially if the sysctl net.core.high_order_alloc_disable value is 1,
then the frag always get a page when do refill.

Which could see reliable crashes or scp failure (scp a file 100M in size
to VM).

The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning
of a new frag. When the frag size is larger than PAGE_SIZE,
everything is fine. However, if the frag is only one page and the
total size of the buffer and virtnet_rq_dma is larger than one page, an
overflow may occur.

The commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever
use_dma_api") introduced this problem. And we reverted some commits to
fix this in last linux version. Now we try to enable it and fix this
bug directly.

Here, when the frag size is not enough, we reduce the buffer len to fix
this problem.


Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.12.5, 6.13, 6.6.66
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a8f7d6963768b114ec9644ff0148dde4c104e84b
CVE-2024-57852: kernel: firmware: qcom: scm: smc: Handle missing SCM device
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

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

Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer
dereference") makes it explicit that qcom_scm_get_tzmem_pool() can
return NULL, therefore its users should handle this.


Affected upstream versions: 6.11.8 < 6.12, 6.12
Fixed upstream versions: 0, 6.12, 6.12.16, 6.13.4, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cd955b75849b58b650ca3f87b83bd78cde1da8bc
CVE-2024-57876: kernel: drm/dp_mst: Fix resetting msg rx state after topology removal
Component: kernel
Severity: Moderate
CVSS v3: 4.6 (CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply
or MST up request sideband message, the
drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset
from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with
the reading/parsing of the message from another thread via
drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is
possible since the reader/parser doesn't hold any lock while accessing
the reception state. This in turn can lead to a memory corruption in the
reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST
sideband message body length check").

Fix the above by resetting the message reception state if needed before
reading/parsing a message. Another solution would be to hold the
drm_dp_mst_topology_mgr::lock for the whole duration of the message
reception/parsing in drm_dp_mst_handle_down_rep() and
drm_dp_mst_handle_up_req(), however this would require a bigger change.
Since the fix is also needed for stable, opting for the simpler solution
in this patch.


Affected upstream versions: 6.1.18 < 6.1.120, 5.10.173 < 5.11, 5.15.100 < 5.16, 6.2.5 < 6.3, 6.3
Fixed upstream versions: 0, 5.11, 5.16, 6.1.120, 6.12.5, 6.13, 6.3, 6.6.66
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 94b33b2d7640e807869451384eb88321dd0ffbd4
CVE-2024-57879: kernel: Bluetooth: iso: Always release hdev at the end of iso_listen_bis
Component: kernel
Severity: Moderate
CWE: CWE-404 (Improper Resource Shutdown or Release)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: iso: Always release hdev at the end of iso_listen_bis

Since hci_get_route holds the device before returning, the hdev
should be released with hci_dev_put at the end of iso_listen_bis
even if the function returns with an error.


Affected upstream versions: 6.8.12 < 6.9, 6.9
Fixed upstream versions: 0, 6.12.6, 6.13, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4ca50db1c567d658d173c5ef3ee6c52b0b03603c
CVE-2024-57888: kernel: workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-15T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker

After commit
746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
amdgpu started seeing the following warning:

 [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]
...
 [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]
...
 [ ] Call Trace:
 [ ]  <TASK>
...
 [ ]  ? check_flush_dependency+0xf5/0x110
...
 [ ]  cancel_delayed_work_sync+0x6e/0x80
 [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]
 [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]
 [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]
 [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]
 [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]
 [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]
 [ ]  process_one_work+0x217/0x720
...
 [ ]  </TASK>

The intent of the verifcation done in check_flush_depedency is to ensure
forward progress during memory reclaim, by flagging cases when either a
memory reclaim process, or a memory reclaim work item is flushed from a
context not marked as memory reclaim safe.

This is correct when flushing, but when called from the
cancel(_delayed)_work_sync() paths it is a false positive because work is
either already running, or will not be running at all. Therefore
cancelling it is safe and we can relax the warning criteria by letting the
helper know of the calling context.

References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")


Affected upstream versions: 4.5
Fixed upstream versions: 0, 6.12.9, 6.13, 6.6.72
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1fd2a57dcb4de3cb40844a29c71b5d7b46a84334