Filipe Manana

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: A vulnerability in the Linux kernel has been resolved, related to the btrfs file system. The issue occurs when updating the action of an existing reference to BTRFS DROP DELAYED REF, which deletes the reference from its list using `list del()`. This leaves the reference's `add list` member not reinitialized, causing a crash when `drop delayed ref()` is called later. The crash happens because `list empty()` returns false due to the list not being reinitialized after `list del()`, leading to an invalid list access. This results in a splat if `CONFIG LIST HARDENED` and `CONFIG DEBUG LIST` are set, or invalid poison pointer dereferences otherwise. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: The issue is related to a race condition in the btrfs file system, specifically in the `find desired extent()` function. When multiple threads access the same file descriptor concurrently, a memory leak can occur due to the allocation of private structures by each thread. This can lead to a use-after-free problem, as one thread may free the structure while another is still using it. The issue arises from the shared use of the same cached state record in the private structure, which can result in incorrect results. The problem is fixed by protecting the private assignment and check of a file while holding the inode's spinlock and keeping track of the task that allocated the private. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider restricting concurrent access to the same file descriptor to minimize the risk of exploitation. Additionally, avoid using the `lseek` system call with `SEEK DATA` or `SEEK HOLE` flags on the same file descriptor from multiple threads.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة: إصدارات نواة لينكس الأقدم من 6.6.74 الوصف: تم إصلاح ثغرة أمنية في نواة لينكس، وتحديدًا في وحدة btrfs. تتعلق المشكلة بتعطل تكراري محتمل تم اكتشافه عند تشغيل fstests btrfs/011 مع MKFS OPTIONS="-O rst". وقد يؤدي ذلك إلى حدوث حالة تعطل تام. تنشأ هذه الثغرة الأمنية عندما يحاول الوحدة النمطية btrfs الحصول على قفل (lock) تحتفظ به المهمة بالفعل. تتضمن التفاصيل الفنية حول استغلال الثغرة الدالة `btrfs map block()` والقفل `dev replace.rwsem`. التوصيات: لحل المشكلة، قم بتحديث نواة لينكس إلى الإصدار 6.6.74 أو أحدث. كحل مؤقت، يُنصح بتعطيل الدالة `btrfs dev replace by ioctl()` حتى يتوفر تصحيح. قم بتقييد الوصول إلى الدالة `btrfs map block()` لتقليل مخاطر الاستغلال. تجنب استخدام قفل `dev replace.rwsem` في نقاط نهاية واجهة برمجة التطبيقات (API) المتأثرة حتى يتم حل المشكلة.

The issue is related to a use-after-free vulnerability in the btrfs load zone info() function, which can be triggered by a race condition with a device replace operation. This happens because the function extracts a device from the chunk map into a local variable and then uses the device while not under the protection of the device replace rwsem. If a device replace operation occurs while the device is being extracted and the device is the source of the replace operation, a use-after-free can be triggered if the replace operation finishes and frees the device before the function finishes using it. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited.

The issue is related to a race condition in the btrfs file system when detecting delalloc ranges during fiemap. This can lead to missing delalloc ranges for file regions that are currently holes, causing the caller of fiemap to be unaware of data in some file regions. This can be serious for use cases like the cp program in coreutils versions before 9.0, which used fiemap to detect holes and data in the source file. If cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, resulting in a data loss issue. Technical details about exploitation include: - The `fiemap` function is called without the `FIEMAP FLAG SYNC` flag for a file with delalloc in a range that is currently a hole. - The `fiemap` function locks the inode in shared mode and iterates the inode's subvolume tree searching for file extent items without having the whole fiemap target range locked in the inode's io tree. - The `btrfs find delalloc in range()` function is used to search for delalloc by checking for the `EXTENT DELALLOC` bit in the io tree for the range and ordered extents.

قد يحدث تعطل متبادل (deadlock) في نواة لينكس عندما تبدأ عملية إلغاء التثبيت (unmount) أثناء تنفيذ مهمة استرداد مجموعة الكتل غير المتزامنة (asynchronous block group recovery) وإعادة تخصيص مجموعة كتل البيانات. ويحدث ذلك بسبب مجموعة من العوامل، بما في ذلك وجود مهمة استرداد مساحة البيانات أو البيانات الوصفية غير المتزامنة، وتوقف kthread cleaner أثناء عملية close ctree(). تظهر المشكلة عندما تنفذ مهمة استرداد المساحة غير المتزامنة جميع عمليات الإدخال المؤجلة (delayed inputs) الموجودة، وتقوم مهمة استرداد مجموعة الكتل بإنشاء عملية إدخال مؤجلة، مما يؤدي إلى حدوث حالة تعطل.

The issue is related to a use-after-free vulnerability in the Linux kernel's btrfs file system. Specifically, it occurs when creating a snapshot and the `btrfs commit transaction()` function fails, leading to a situation where a pending snapshot structure is freed but still accessible, resulting in a user-after-free scenario. This can happen in the following sequence: 1. A pending snapshot is allocated and added to the transaction's list of pending snapshots. 2. `btrfs commit transaction()` is called, and if it fails, the pending snapshot structure is freed. 3. Another task commits the transaction without errors, accessing the already freed pending snapshot structure, thus causing a user-after-free. The vulnerability could be detected by smatch, which produced a warning about the pending snapshot not being removed from the list. To fix this, the snapshot creation ioctl should not directly add the pending snapshot to the transaction's list. Instead, it should add the pending snapshot to the transaction handle, and then at `btrfs commit transaction()`, add the snapshot to the list only when it can be guaranteed that any error returned after that point will result in a transaction abort.

The vulnerability is related to the btrfs file system in the Linux kernel. When an inode is moved from one directory to another and both the inode and its previous parent directory were logged before, the dentry for the old parent should not exist after a power failure if the log is synced. However, there is a scenario where this does not work correctly because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This can be triggered by a specific layout of keys and items in the fs/subvolume btree.

A race condition exists between a task aborting a transaction during a commit, a task doing an fsync, and the transaction kthread, leading to a use-after-free of the log root tree. This results in a stack trace with errors such as "BTRFS info (device dm-0): forced readonly" and "BTRFS: error (device dm-0) in cleanup transaction:1958: errno=-5 IO failure". The issue occurs when two tasks have a transaction handle attached to the same transaction, and one task is doing an fsync while the other task calls btrfs commit transaction(), causing an error before the transaction is committed.

The issue allows local users to gain privileges or cause a denial of service (use-after-free) by leveraging improper access to a certain error field in the ext4 journal stop function.