CVE-2023-53854 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
ASoC: mediatek: mt8186: إصلاح مشكلة Use-After-Free في مسار إزالة (remove) السائق (driver).
عندما يقوم `devm` بتشغيل الوظائف في المسار "إزالة" لجهاز ما، فإنه ينفذها بالترتيب العكسي. وهذا يعني أنه إذا كانت لديك أجزاء من سائقك لا تستخدم `devm` أو تستخدم تنفيذًا مخصصًا لـ `devm` عبر دالة `devm_add_action_or_reset()`، فيجب أن تأخذ ذلك بعين الاعتبار.
لم يقم السائق الصوتي الخاص بـ mt8186 بضبط هذا بشكل صحيح تمامًا. وتحديداً، داخل الدالة `mt8186_init_clock()`، تم استدعاء `mt8186_audsys_clk_register()` ثم الانتقال إلى استدعاء مجموعة من دوال `devm` الأخرى. استخدم مُستدعي `mt8186_init_clock()` دالة `devm_add_action_or_reset()` لاستدعاء `mt8186_deinit_clock()`، ولكن بسبب وجود دوال `devm` بينهما، أصبح الترتيب خاطئًا.
تحديداً في وقت الفحص (probe)، كان الترتيب كالتالي: 1. `mt8186_audsys_clk_register()` 2. `afe_priv->clk = devm_kcalloc(...)` 3. `afe_priv->clk[i] = devm_clk_get(...)`
أما في وقت الإزالة (remove)، فكان الترتيب (الذي كان ينبغي أن يكون 3، ثم 2، ثم 1) كالتالي: 1. `mt8186_audsys_clk_unregister()` 3. تحرير جميع عناصر `afe_priv->clk[i]`
2. تحرير `afe_priv->clk`
يبدو أن ما سبق كان يسبب مشكلة Use-After-Free. ولحسن الحظ، من السهل إصلاح ذلك ببساطة باستخدام `devm` بشكل صحيح أكثر. دعنا ننقل استدعاء `devm_add_action_or_reset()` إلى المكان الصحيح. بالإضافة إلى إصلاح الـ use-after-free، يُظهر فحص الكود أن هذا الإصلاح يصحّح أيضًا تسربًا ذاكرة (نقصان في استدعاء `mt8186_audsys_clk_unregister()`) كان سيحدث لو فشلت أي من مكالمات `syscon_regmap_lookup_by_phandle()` داخل دالة `mt8186_init_clock()`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.