Race Condition Affecting kernel-default-devel package, versions <5.14.21-150500.55.80.2
Threat Intelligence
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.
Do your applications use this vulnerable package?
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 applications- Snyk IDSNYK-SLES155-KERNELDEFAULTDEVEL-8104071
- published28 Sept 2024
- disclosed27 Sept 2024
Introduced: 27 Sep 2024
CVE-2022-48898 (opens in a new tab)How to fix?
Upgrade SLES:15.5 kernel-default-devel to version 5.14.21-150500.55.80.2 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-default-devel package and not the kernel-default-devel package as distributed by SLES.
See How to fix? for SLES:15.5 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set.
Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption.
Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID
Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text
Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller
Changes in v4: -- split into two patches
Changes in v5: -- delete empty line between tags
Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text
References
- https://www.suse.com/security/cve/CVE-2022-48898.html
- https://bugzilla.suse.com/1229537
- https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169
- https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1
- https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a
- https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59