In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix softlockup in __read_vmcore (part 2)
Since commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore") the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.
In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.
The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.
Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.
CVSS
5.5 MEDIUM (v3.1, CISA ADP)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
803d5a33d5ffdc2d86dcc0cfa01655a330612cdb builds before 84c4ed15626574c9ac6c1039ba9c137a77bcc7f2; from 70c1835e776c8447c1aca87ddb38cfe764fe756a before 80da29deb88a3a907441fc35bb7bac309f31e713; from e1b160a50c756e0efbea290b9bf5117cb80e8c4b before 649b266606bc413407ce315f710c8ce8a88ee30a; from a373ad833a6bfe4bc6cedcf7e56a99cc6fd9a193 before 65c367bd9d4f43513c7f837df5753bea9561b836; from 518fbd644dabb6aedbdd4939c6c9cc1bf651459f before a5a2ee8144c3897d37403a69118c3e3dc5713958; from 5cbcb62dddf5346077feb82b7b0c9254222d3445 before 80828540dad0757b6337c6561d49c81038f38d87; from 5cbcb62dddf5346077feb82b7b0c9254222d3445 before cbc5dde0a461240046e8a41c43d7c3b76d5db952; 7bdf1d550ddfcd9ab797087421f77b7aceddc8a7; and 8 more ranges
from 4.19.317 before 4.20; from 5.4.279 before 5.4.290; from 5.10.221 before 5.10.234; from 5.15.162 before 5.15.177; from 6.1.95 before 6.1.127; from 6.6.35 before 6.6.74; from 6.9.6 before 6.12.11; 6.13; and 6 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.