{"uuid": "7c91ccc9-85f7-4145-8ff7-c2ade979c889", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2022-48920", "type": "seen", "source": "https://t.me/cvedetector/3854", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2022-48920 - Btrfs flushoncommit warning vulnerability\", \n  \"Content\": \"CVE ID : CVE-2022-48920 \nPublished : Aug. 22, 2024, 2:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbtrfs: get rid of warning on transaction commit when using flushoncommit  \n  \nWhen using the flushoncommit mount option, during almost every transaction  \ncommit we trigger a warning from __writeback_inodes_sb_nr():  \n  \n  $ cat fs/fs-writeback.c:  \n  (...)  \n  static void __writeback_inodes_sb_nr(struct super_block *sb, ...  \n  {  \n        (...)  \n        WARN_ON(!rwsem_is_locked(&sb->s_umount));  \n        (...)  \n  }  \n  (...)  \n  \nThe trace produced in dmesg looks like the following:  \n  \n  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3  \n  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif  \n  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186  \n  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3  \n  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)  \n  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246  \n  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000  \n  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50  \n  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000  \n  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488  \n  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460  \n  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000  \n  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0  \n  [947.571072] Call Trace:  \n  [947.572354]    \n  [947.573266]  btrfs_commit_transaction+0x1f1/0x998  \n  [947.576785]  ? start_transaction+0x3ab/0x44e  \n  [947.579867]  ? schedule_timeout+0x8a/0xdd  \n  [947.582716]  transaction_kthread+0xe9/0x156  \n  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407  \n  [947.590104]  kthread+0x131/0x139  \n  [947.592168]  ? set_kthread_struct+0x32/0x32  \n  [947.595174]  ret_from_fork+0x22/0x30  \n  [947.597561]    \n  [947.598553] ---[ end trace 644721052755541c ]---  \n  \nThis is because we started using writeback_inodes_sb() to flush delalloc  \nwhen committing a transaction (when using -o flushoncommit), in order to  \navoid deadlocks with filesystem freeze operations. This change was made  \nby commit ce8ea7cc6eb313 (\"btrfs: don't call btrfs_start_delalloc_roots  \nin flushoncommit\"). After that change we started producing that warning,  \nand every now and then a user reports this since the warning happens too  \noften, it spams dmesg/syslog, and a user is unsure if this reflects any  \nproblem that might compromise the filesystem's reliability.  \n  \nWe can not just lock the sb->s_umount semaphore before calling  \nwriteback_inodes_sb(), because that would at least deadlock with  \nfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()  \nis called while we are holding that semaphore in write mode, and that can  \ntrigger a transaction commit, resulting in a deadlock. It would also  \ntrigger the same type of deadlock in the unmount path. Possibly, it could  \nalso introduce some other locking dependencies that lockdep would report.  \n  \nTo fix this call try_to_writeback_inodes_sb() instead of  \nwriteback_inodes_sb(), because that will try to read lock sb->s_umount  \nand then will only call writeback_inodes_sb() if it was able to lock it.  \nThis is fine because the cases where it can't read lock sb->s_umount  \nare during a filesystem unmount or during a filesystem freeze - in those  \ncases sb->s_umount is write locked and sync_filesystem() is called, which  \ncalls writeback_inodes_sb(). In other words, in all cases where we can[...]", "creation_timestamp": "2024-08-22T05:07:54.000000Z"}