هسته لینوکس 7.3 یک اشکال سیستم FAT را که نام‌های فایل را بدون هشدار کوتاه می‌کرد، اصلاح می‌کند

**هسته لینوکس 7.3 یک اصلاحیه برای درایور سیستم‌های فایل FAT را شامل می‌شود که برای سال‌ها نام‌های فایل طولانی‌تر از حد مجاز را پذیرفته و به‌طور خاموش آن‌ها را کوتاه می‌کرد و باعث رفتارهای غیرمنتظره می‌شد. این اشکال که توسط یک مهندس هوآوی کشف شد، به یکپارچگی داده‌ها آسیب می‌زد و هنگام استفاده از توابعی مانند open() هشدارهایی از هسته تولید می‌کرد، هرچند که vfat تحت تأثیر قرار نگرفته است.

یک اشکال خاموش در قلب FAT

درایور سیستم فایل FAT لینوکس که مسئول پشتیبانی از FAT12، FAT16 و FAT32 است، به ندرت به‌روزرسانی‌های مهمی دریافت می‌کند، اما برای لینوکس 7.3 یک وصله‌ای به‌وجود آمد که رفتار معیوبی را اصلاح می‌کند که ممکن است برای مدت طولانی نادیده گرفته شود. مشکل در عدم وجود یک بررسی محدودیت بالایی در طول نام‌های فایل بود که اجازه می‌داد نام‌های بسیار طولانی به‌طور خاموش کوتاه شوند و وضعیت‌های غیرمنتظره‌ای ایجاد کنند.

زمانی که یک نام فایل از محدودیت NAME_MAX لینوکس که 255 بایت است، فراتر می‌رفت، درایور طول اضافی را بدون هیچ گونه هشدار کوتاه می‌کرد و به‌طور معمول ادامه می‌داد گویی که عملیات موفقیت‌آمیز بوده است. این رفتار عمدی نبود، زیرا هنگام خواندن بعدی آن فایل‌ها، سیستم فقط با بایت‌های کوتاه شده مطابقت داشت که می‌توانست به عدم سازگاری و احتمال از دست رفتن داده‌ها منجر شود.

مهندس هوآوی، زی‌زی وو، کسی بود که مشکل را در درایور FAT شناسایی و حل کرد و در پیام وصله توضیح داد که تابع msdos_format_name() هیچ بررسی محدودیت بالایی در طول نام ورودی انجام نمی‌داد.

خطر با نام‌های بسیار طولانی

برای نشان دادن شدت این اشکال، وو یک مثال خاص ارائه داد: ارسال یک نام 300 بایتی که فقط از 'A' تشکیل شده بود، 0 را به عنوان موفقیت برمی‌گرداند، با res تنظیم شده به "AAAAAAAA" (هشت 'A' و سه فضای پرکننده)، موفقیت را برای نامی بسیار طولانی‌تر از NAME_MAX گزارش می‌کرد. این سناریو نه تنها گیج‌کننده بود، بلکه می‌توانست رفتارهای غیرعادی در هسته را تحریک کند.

زمانی که یک کاربر open() را با یک مؤلفه مسیر طولانی‌تر از 255 بایت فراخوانی می‌کرد، سیستم VFS فقط PATH_MAX را اعمال می‌کرد، نه طول یک مؤلفه فردی، بنابراین dentry نام طولانی اصلی را حفظ می‌کرد اما به آن یک inode اختصاص داده می‌شد و مثبت می‌شد. این باعث ایجاد یک هشدار در vfs_open() می‌شد که به fsnotify_open() و fanotify_info_copy_name() منتقل می‌شد، جایی که WARN_ON_ONCE() فعال می‌شد و رویداد به فضای کاربر با یک نام خالی گزارش می‌شد.

تأثیر این موضوع فقط به یک هشدار آزاردهنده محدود نمی‌شد، بلکه می‌توانست بر سیستم‌هایی که به fanotify برای نظارت بر رویدادهای سیستم فایل وابسته بودند، تأثیر بگذارد. یک نام خالی در رویداد می‌توانست منطق برنامه‌هایی که به آن اطلاعات وابسته بودند را مختل کند و منجر به آسیب‌پذیری‌های بالقوه یا نقص در نظارت امنیتی شود.

خوشبختانه، سیستم فایل vfat تحت تأثیر این مشکل قرار نگرفته است، زیرا ایجاد آن از طریق xlate_to_uni() انجام می‌شود که نام‌های طولانی‌تر از FAT_LFN_LEN، یک محدودیت 255 کاراکتری را رد می‌کند.

اصلاحیه پیشنهادی هوآوی

راه‌حل پیاده‌سازی شده یک بررسی "len > NAME_MAX" را در ورودی msdos_format_name() اضافه می‌کند که تنها نقطه ورودی برای تمام مدیریت نام‌های msdos در درایور است. این بررسی با آنچه که xfs، 9p، ceph و simple_lookup() در جستجو انجام می‌دهند، هم‌راستا است و اطمینان می‌دهد که هیچ نامی از محدودیت تعیین شده توسط سیستم فراتر نرود.

این رویکرد تضمین می‌کند که از هسته لینوکس 7.3 به بعد، هرگونه تلاش برای استفاده از یک نام فایل طولانی‌تر از 255 بایت در سیستم‌های FAT به‌طور کنترل‌شده‌ای رد خواهد شد، به جای اینکه به‌طور خاموش کوتاه شود. این اصلاح همچنین از فعال شدن هشدارهای غیرضروری در هسته جلوگیری می‌کند و ثبات و امنیت سیستم را بهبود می‌بخشد.

این وصله ارسال شده و اکنون برای لینوکس 7.3 ادغام شده است و انتظار می‌رود که به هسته‌های پایدار نیز در آینده نزدیک برگردانده شود تا کاربران توزیع‌هایی که نسخه‌های قدیمی‌تری از هسته را حفظ می‌کنند، بتوانند از این اصلاح بهره‌مند شوند.

این نوع اشکالات، هرچند در یک درایور قدیمی مانند FAT نادر است، اهمیت به‌روزرسانی سیستم‌ها و بررسی کدهایی که عملیات‌های حیاتی مانند دسترسی به فایل‌ها را مدیریت می‌کنند، را زیر سؤال می‌برد.