Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%
Buy Us a Coffee

CVE-2026-99183— accel/rocket: search every core slot when looking up a scheduler

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中，以下漏洞已得到修复： accel/rocket：在查找调度器时，需遍历每一个核心槽位。 sched_to_core() 函数会遍历 rdev->cores[] 数组，范围从索引 0 到 rdev->num_cores；而 rocket_remove() 在移除每个核心时，都会将 num_cores 减一。如果解除绑定的核心不是最后一个，那么它之后的核心就会落在搜索范围之外，导致 sched_to_core() 对一个仍然处于绑定状态且正在执行任务的返回 NULL。然而，该函数的两个调用方均未

AI Predicted 7.8 Difficulty: Moderate

Affected Version Matrix 6

VendorProduct Version RangeStatus
Linux Linux 0810d5ad88a18f1e6d549853a388ad0316f74e36< c137756469d5bcc79e97beb406ae4d14b9585463 affected
0810d5ad88a18f1e6d549853a388ad0316f74e36< 89c2c777df17eb0201c8e22afabbf3691f2a28fe affected
6.18 affected
< 6.18 unaffected
7.2.13≤ 7.2.* unaffected
7.3≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-99183

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
accel/rocket: search every core slot when looking up a scheduler
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when looking up a scheduler sched_to_core() walks rdev->cores[] up to rdev->num_cores, and rocket_remove() decrements num_cores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so sched_to_core() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result: rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out") Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core's job queue and once from its reset work: KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched] pc : rocket_job_run+0x234/0x838 [rocket] Call trace: rocket_job_run+0x234/0x838 [rocket] drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched] process_one_work+0x640/0x14f0 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched] pc : rocket_job_timedout+0xf0/0x1e0 [rocket] Call trace: rocket_job_timedout+0xf0/0x1e0 [rocket] drm_sched_job_timedout+0x188/0x6a0 [gpu_sched] Both are the third core: the workqueue names are its device and its core->index, and it was left at slot 2 while num_cores had dropped to 2. Search all the slots that were allocated, the way find_core_for_dev() now does. A core that is still bound is then found, and the two callers get the pointer they already assume they have. This does not make unbinding one core out of several safe. An open client keeps an entity pointing at the scheduler of the core that went away: drm_sched reports it as not ready for every job that lands on it, and the client waits in dma_fence_default_wait for a fence that will never signal. Stopping the NULL dereference is what belongs in a fix; the rest wants more thought.
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 0810d5ad88a18f1e6d549853a388ad0316f74e36 ~ c137756469d5bcc79e97beb406ae4d14b9585463 -
Linux Linux 6.18 -

II. Public POCs for CVE-2026-99183

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-99183

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-99183 (2)

Same Patch Batch · Linux · 2026-10-28 · 117 CVEs total

CVE-2026-99143 tracing: Keep the predicate limit separate from program capacity
CVE-2026-99129 selinux: fix BPF token permission checks
CVE-2026-99130 io_uring/cancel: don't spin on local work the task can't run
CVE-2026-99131 xfs: fix capability check in xfs
CVE-2026-99133 net/iucv: fix the recvmsg window update
CVE-2026-99132 xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf
CVE-2026-99134 mac802154: fix data race and NULL deref on local->assoc_dev
CVE-2026-99135 dm-integrity: fix infinite loop on discard with large tag size
CVE-2026-99137 cifs: don't update i_size in cifs_do_truncate without a cached handle
CVE-2026-99136 dm-crypt: fix a tiny race condition in crypt_dec_pending
CVE-2026-99138 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO)
CVE-2026-99140 tracing: Fix hist trigger timestamps for buffered events
CVE-2026-99139 tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION)
CVE-2026-99141 tracing: Fix crash in print_graph_function_event()
CVE-2026-99142 tracing: Check operator stack capacity before pushing
CVE-2026-99154 scsi: libiscsi: Reject a negative task index from parse_pdu_itt
CVE-2026-99151 drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functions
CVE-2026-99153 scsi: libiscsi: Validate the ITT reflected in a Reject PDU
CVE-2026-99152 scsi: libiscsi: Validate the task named by a management response
CVE-2026-99150 drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gpr

Showing top 20 of 117 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

Same product: Linux
Same vendor: Linux