Към съдържанието
Търсене

CVE-2026-53145: Linux, състезание за ресурс

7.8

CVSS 3.1

Няма данни

Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)

Няма потвърждение

Атакува се

Няма данни

Време до експлоатация

Атакува се локално, без особени условия, с обикновен потребителски вход и без действие от потребителя.

CVE радар: още уязвимости от този вид

  • Експлоатация: няма данни за експлоатация
  • Атаката не може да се автоматизира

Описание

Оригинално описание

In the Linux kernel, the following vulnerability has been resolved: drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my abilit

Засегнати продукти

  • Linux Linux: 672464dd53231509c9c771110798c56d4660e19e преди c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cd; 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025 преди 1d9b93df7fc768228906e24220591ec1cddad391; 5e28b7b94408897e41c63477aabc9e1db439bc8c преди 1a4f03d22fb655e5f192244fb2c87d8066fcfca2; 318b995cffcfcaa69a234d28123a3f4ae186a9df; 38f12d0e10d83b66fa1466400d876a3a8da31542; 0dfa42cfe4dbe114533480503934f43e33c1e83d; cde2c9257cbe8463b9dcf7b1075177b72b5fd938
  • Linux Linux: 6.18.32 преди 6.18.36; 7.0.9 преди 7.0.13
  • Red Hat: още 5 продукта, добавени от Red Hat

    Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9

Вид слабост

История

  • 25 юни 2026 Публикувано

Други уязвимости в Linux Linux

Първоизточници