{"api_version":"1","generated_at":"2026-09-26T23:26:51+00:00","cve":"CVE-2026-97900","urls":{"html":"https://cve.report/CVE-2026-97900","api":"https://cve.report/api/cve/CVE-2026-97900.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-97900","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-97900"},"summary":{"title":"drm/drm_exec: fix up contended obj when num_objects is 0","description":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_exec: fix up contended obj when num_objects is 0\n\ndrm_exec_prepare_array() silently returns success without calling\ndrm_exec_lock_contended() when num_objects is zero. This breaks the\ninvariant upheld by drm_exec_lock_obj(), where every entry point into\nthe locking sequence must first attempt to lock any previously\ncontended object before proceeding.\n\nDrivers that chain multiple drm_exec_prepare_array() calls per\ndrm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait\nioctls, which prepare separate read and write BO arrays) can pass an\nempty array for one of the two calls. If contention is hit while\npreparing the non-empty array, exec->contended is set and the loop\nretries; on retry, the empty-array call preceding it is a no-op that\nnever clears exec->contended, so drm_exec_retry_on_contention()\nimmediately jumps back to the top of the loop without ever reaching\nthe call that would resolve the contention. This spins forever.\n\nFix it by having drm_exec_prepare_array() call drm_exec_lock_contended()\ndirectly when num_objects is zero, so a pending contended object dont\nloop infinitely.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-25 11:17:16","updated_at":"2026-09-25 11:17:16"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/159720704d9d652b64390c11fb971e15b0a78d23","name":"https://git.kernel.org/stable/c/159720704d9d652b64390c11fb971e15b0a78d23","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/f3e74866018dab793ebee1fdf0ef34f7271d1f8c","name":"https://git.kernel.org/stable/c/f3e74866018dab793ebee1fdf0ef34f7271d1f8c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/831cd124ce99c3e61266bed30519d52f7c26abed","name":"https://git.kernel.org/stable/c/831cd124ce99c3e61266bed30519d52f7c26abed","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a565022c02f218ec9789c2baf4690792e7a48cbb","name":"https://git.kernel.org/stable/c/a565022c02f218ec9789c2baf4690792e7a48cbb","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-97900","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-97900","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 09593216bff15866f95c8ad406cb7fdcec1ee40a 831cd124ce99c3e61266bed30519d52f7c26abed git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 09593216bff15866f95c8ad406cb7fdcec1ee40a f3e74866018dab793ebee1fdf0ef34f7271d1f8c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 09593216bff15866f95c8ad406cb7fdcec1ee40a a565022c02f218ec9789c2baf4690792e7a48cbb git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 09593216bff15866f95c8ad406cb7fdcec1ee40a 159720704d9d652b64390c11fb971e15b0a78d23 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.6","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.111 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.53 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.7 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/gpu/drm/drm_exec.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"831cd124ce99c3e61266bed30519d52f7c26abed","status":"affected","version":"09593216bff15866f95c8ad406cb7fdcec1ee40a","versionType":"git"},{"lessThan":"f3e74866018dab793ebee1fdf0ef34f7271d1f8c","status":"affected","version":"09593216bff15866f95c8ad406cb7fdcec1ee40a","versionType":"git"},{"lessThan":"a565022c02f218ec9789c2baf4690792e7a48cbb","status":"affected","version":"09593216bff15866f95c8ad406cb7fdcec1ee40a","versionType":"git"},{"lessThan":"159720704d9d652b64390c11fb971e15b0a78d23","status":"affected","version":"09593216bff15866f95c8ad406cb7fdcec1ee40a","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/gpu/drm/drm_exec.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.6"},{"lessThan":"6.6","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.111","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.53","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.7","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.111","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.53","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.7","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc3","versionStartIncluding":"6.6","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_exec: fix up contended obj when num_objects is 0\n\ndrm_exec_prepare_array() silently returns success without calling\ndrm_exec_lock_contended() when num_objects is zero. This breaks the\ninvariant upheld by drm_exec_lock_obj(), where every entry point into\nthe locking sequence must first attempt to lock any previously\ncontended object before proceeding.\n\nDrivers that chain multiple drm_exec_prepare_array() calls per\ndrm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait\nioctls, which prepare separate read and write BO arrays) can pass an\nempty array for one of the two calls. If contention is hit while\npreparing the non-empty array, exec->contended is set and the loop\nretries; on retry, the empty-array call preceding it is a no-op that\nnever clears exec->contended, so drm_exec_retry_on_contention()\nimmediately jumps back to the top of the loop without ever reaching\nthe call that would resolve the contention. This spins forever.\n\nFix it by having drm_exec_prepare_array() call drm_exec_lock_contended()\ndirectly when num_objects is zero, so a pending contended object dont\nloop infinitely."}],"providerMetadata":{"dateUpdated":"2026-09-25T10:22:28.057Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/831cd124ce99c3e61266bed30519d52f7c26abed"},{"url":"https://git.kernel.org/stable/c/f3e74866018dab793ebee1fdf0ef34f7271d1f8c"},{"url":"https://git.kernel.org/stable/c/a565022c02f218ec9789c2baf4690792e7a48cbb"},{"url":"https://git.kernel.org/stable/c/159720704d9d652b64390c11fb971e15b0a78d23"}],"title":"drm/drm_exec: fix up contended obj when num_objects is 0","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-97900","datePublished":"2026-09-25T10:22:28.057Z","dateReserved":"2026-09-25T10:18:58.200Z","dateUpdated":"2026-09-25T10:22:28.057Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-25 11:17:16","lastModifiedDate":"2026-09-25 11:17:16","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"97900","Ordinal":"1","Title":"drm/drm_exec: fix up contended obj when num_objects is 0","CVE":"CVE-2026-97900","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"97900","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_exec: fix up contended obj when num_objects is 0\n\ndrm_exec_prepare_array() silently returns success without calling\ndrm_exec_lock_contended() when num_objects is zero. This breaks the\ninvariant upheld by drm_exec_lock_obj(), where every entry point into\nthe locking sequence must first attempt to lock any previously\ncontended object before proceeding.\n\nDrivers that chain multiple drm_exec_prepare_array() calls per\ndrm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait\nioctls, which prepare separate read and write BO arrays) can pass an\nempty array for one of the two calls. If contention is hit while\npreparing the non-empty array, exec->contended is set and the loop\nretries; on retry, the empty-array call preceding it is a no-op that\nnever clears exec->contended, so drm_exec_retry_on_contention()\nimmediately jumps back to the top of the loop without ever reaching\nthe call that would resolve the contention. This spins forever.\n\nFix it by having drm_exec_prepare_array() call drm_exec_lock_contended()\ndirectly when num_objects is zero, so a pending contended object dont\nloop infinitely.","Type":"Description","Title":"drm/drm_exec: fix up contended obj when num_objects is 0"}]}}}