The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsThere is no fixed version for RHEL:10
kernel
.
Note: Versions mentioned in the description apply only to the upstream kernel
package and not the kernel
package as distributed by RHEL
.
See How to fix?
for RHEL:10
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
fs/eventpoll: fix endless busy loop after timeout has expired
After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the future"), the following program would immediately enter a busy loop in the kernel:
int main() {
int e = epoll_create1(0);
struct epoll_event event = {.events = EPOLLIN};
epoll_ctl(e, EPOLL_CTL_ADD, 0, &event);
const struct timespec timeout = {.tv_nsec = 1};
epoll_pwait2(e, &event, 1, &timeout, 0);
}
This happens because the given (non-zero) timeout of 1 nanosecond
usually expires before ep_poll() is entered and then
ep_schedule_timeout() returns false, but timed_out
is never set
because the code line that sets it is skipped. This quickly turns
into a soft lockup, RCU stalls and deadlocks, inflicting severe
headaches to the whole system.
When the timeout has expired, we don't need to schedule a hrtimer, but
we should set the timed_out
variable. Therefore, I suggest moving
the ep_schedule_timeout() check into the timed_out
expression
instead of skipping it.
brauner: Note that there was an earlier fix by Joe Damato in response to my bug report in [1].