Loading HuntDB...

CVE-2024-26785

MEDIUM
Published 2024-04-04T08:20:18.467Z
Actions:

CVSS Score

V3.1
5.5
/10
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Base Score Metrics
Exploitability: N/A Impact: N/A

EPSS Score

v2023.03.01
0.000
probability
of exploitation in the wild

There is a 0.0% chance that this vulnerability will be exploited in the wild within the next 30 days.

Updated: 2025-01-25
Exploit Probability
Percentile: 0.178
Higher than 17.8% of all CVEs

Attack Vector Metrics

Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED

Impact Metrics

Confidentiality
NONE
Integrity
NONE
Availability
HIGH

Description

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

iommufd: Fix protection fault in iommufd_test_syz_conv_iova

Syzkaller reported the following bug:

general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7]
Call Trace:
lock_acquire
lock_acquire+0x1ce/0x4f0
down_read+0x93/0x4a0
iommufd_test_syz_conv_iova+0x56/0x1f0
iommufd_test_access_rw.isra.0+0x2ec/0x390
iommufd_test+0x1058/0x1e30
iommufd_fops_ioctl+0x381/0x510
vfs_ioctl
__do_sys_ioctl
__se_sys_ioctl
__x64_sys_ioctl+0x170/0x1e0
do_syscall_x64
do_syscall_64+0x71/0x140

This is because the new iommufd_access_change_ioas() sets access->ioas to
NULL during its process, so the lock might be gone in a concurrent racing
context.

Fix this by doing the same access->ioas sanity as iommufd_access_rw() and
iommufd_access_pin_pages() functions do.

Available Exploits

No exploits available for this CVE.

Related News

No news articles found for this CVE.

Affected Products

References

Published: 2024-04-04T08:20:18.467Z
Last Modified: 2025-05-04T08:56:27.932Z
Copied to clipboard!