What is the CVSS score of CVE-2024-35955?

CVE-2024-35955 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2024-35955?

Yes, a patch is available for CVE-2024-35955. Update the affected software to the latest version immediately.

Debian Linux CVE-2024-35955

HIGH

Use After Free (CWE-416)

2024-05-20 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Information Disclosure Linux Use After Free Memory Corruption Debian Debian Linux Linux Kernel

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

CVE Published

May 20, 2024 - 10:15 cve.org

HIGH 8.8

DescriptionCVE.org

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. is_module_text_address() and __module_text_address() works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use is_module_text_address() and __module_text_address() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations.

In check_kprobe_address_safe(), if the second __module_text_address() is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated is_module_text_address() and __module_text_address(), but use only __module_text_address() once and do try_module_get(module) which is only available with MODULE_STATE_LIVE.

AnalysisAI

In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. This Use After Free vulnerability could allow attackers to access freed memory to execute arbitrary code or crash the application.

Technical ContextAI

This vulnerability is classified as Use After Free (CWE-416), which allows attackers to access freed memory to execute arbitrary code or crash the application. In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. is_module_text_address() and __module_text_address() works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use is_module_text_address() and __module_text_address() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In check_kprobe_address_safe(), if the second __module_text_address() is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated is_module_text_address() and __module_text_address(), but use only __module_text_address() once and do try_module_get(module) which is only available with MODULE_STATE_LIVE. Affected products include: Linux Linux Kernel, Debian Debian Linux.

RemediationAI

A vendor patch is available. Apply the latest security update as soon as possible. Use smart pointers or garbage-collected languages. Set pointers to NULL after freeing. Enable memory sanitizers.