CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
AI Score
Confidence
Low
EPSS
Percentile
13.0%
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.
git.kernel.org/stable/c/2df2dd27066cdba8041e46a64362325626bdfb2e
git.kernel.org/stable/c/325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8
git.kernel.org/stable/c/36b57c7d2f8b7de224980f1a284432846ad71ca0
git.kernel.org/stable/c/5062d1f4f07facbdade0f402d9a04a788f52e26d
git.kernel.org/stable/c/62029bc9ff2c17a4e3a2478d83418ec575413808
git.kernel.org/stable/c/93eb31e7c3399e326259f2caa17be1e821f5a412
git.kernel.org/stable/c/b5808d40093403334d939e2c3c417144d12a6f33
git.kernel.org/stable/c/d15023fb407337028a654237d8968fefdcf87c2f
lists.debian.org/debian-lts-announce/2024/06/msg00017.html
lists.debian.org/debian-lts-announce/2024/06/msg00020.html