)]}'
{
  "commit": "ff0031d848a0cd7002606f9feef958de8d5edf19",
  "tree": "bbc3819f57ac54666716b1c6c5dc21085612edc7",
  "parents": [
    "079788d01e7ba9d7366d7bd2a0db9cab5944e85b"
  ],
  "author": {
    "name": "Carlos Maiolino",
    "email": "cmaiolino@redhat.com",
    "time": "Tue Jul 05 22:02:41 2016 -0400"
  },
  "committer": {
    "name": "Theodore Ts\u0027o",
    "email": "tytso@mit.edu",
    "time": "Tue Jul 05 22:02:41 2016 -0400"
  },
  "message": "ext2: fix filesystem deadlock while reading corrupted xattr block\n\nThis bug can be reproducible with fsfuzzer, although, I couldn\u0027t reproduce it\n100% of my tries, it is quite easily reproducible.\n\nDuring the deletion of an inode, ext2_xattr_delete_inode() does not check if the\nblock pointed by EXT2_I(inode)-\u003ei_file_acl is a valid data block, this might\nlead to a deadlock, when i_file_acl \u003d\u003d 1, and the filesystem block size is 1024.\n\nIn that situation, ext2_xattr_delete_inode, will load the superblock\u0027s buffer\nhead (instead of a valid i_file_acl block), and then lock that buffer head,\nwhich, ext2_sync_super will also try to lock, making the filesystem deadlock in\nthe following stack trace:\n\nroot     17180  0.0  0.0 113660   660 pts/0    D+   07:08   0:00 rmdir\n/media/test/dir1\n\n[\u003cffffffff8125da9f\u003e] __sync_dirty_buffer+0xaf/0x100\n[\u003cffffffff8125db03\u003e] sync_dirty_buffer+0x13/0x20\n[\u003cffffffffa03f0d57\u003e] ext2_sync_super+0xb7/0xc0 [ext2]\n[\u003cffffffffa03f10b9\u003e] ext2_error+0x119/0x130 [ext2]\n[\u003cffffffffa03e9d93\u003e] ext2_free_blocks+0x83/0x350 [ext2]\n[\u003cffffffffa03f3d03\u003e] ext2_xattr_delete_inode+0x173/0x190 [ext2]\n[\u003cffffffffa03ee9e9\u003e] ext2_evict_inode+0xc9/0x130 [ext2]\n[\u003cffffffff8123fd23\u003e] evict+0xb3/0x180\n[\u003cffffffff81240008\u003e] iput+0x1b8/0x240\n[\u003cffffffff8123c4ac\u003e] d_delete+0x11c/0x150\n[\u003cffffffff8122fa7e\u003e] vfs_rmdir+0xfe/0x120\n[\u003cffffffff812340ee\u003e] do_rmdir+0x17e/0x1f0\n[\u003cffffffff81234dd6\u003e] SyS_rmdir+0x16/0x20\n[\u003cffffffff81838cf2\u003e] entry_SYSCALL_64_fastpath+0x1a/0xa4\n[\u003cffffffffffffffff\u003e] 0xffffffffffffffff\n\nFix this by using the same approach ext4 uses to test data blocks validity,\nimplementing ext2_data_block_valid.\n\nAn another possibility when the superblock is very corrupted, is that i_file_acl\nis 1, block_count is 1 and first_data_block is 0. For such situations, we might\nhave i_file_acl pointing to a \u0027valid\u0027 block, but still step over the superblock.\nThe approach I used was to also test if the superblock is not in the range\ndescribed by ext2_data_block_valid() arguments\n\nSigned-off-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Theodore Ts\u0027o \u003ctytso@mit.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9f9992b37924a43eb4da2c56ecb9b65f68d628a2",
      "old_mode": 33188,
      "old_path": "fs/ext2/balloc.c",
      "new_id": "4c40c0786e168bf1c9c92a5c9afe3d538f63142f",
      "new_mode": 33188,
      "new_path": "fs/ext2/balloc.c"
    },
    {
      "type": "modify",
      "old_id": "170939f379d74d84ca38bf9fd11d22483495fd3d",
      "old_mode": 33188,
      "old_path": "fs/ext2/ext2.h",
      "new_id": "3fb93681bf7f7fba5f87bff7d9f9ae37f43e4049",
      "new_mode": 33188,
      "new_path": "fs/ext2/ext2.h"
    },
    {
      "type": "modify",
      "old_id": "fcbe58641e401bf79597a6d3ca0fdea0b5136d87",
      "old_mode": 33188,
      "old_path": "fs/ext2/inode.c",
      "new_id": "d5c7d09919f318066c1be57cf446624875ba229a",
      "new_mode": 33188,
      "new_path": "fs/ext2/inode.c"
    },
    {
      "type": "modify",
      "old_id": "1a5e3bff0b63c93454324a919fc1e008c0bc0193",
      "old_mode": 33188,
      "old_path": "fs/ext2/xattr.c",
      "new_id": "b7f896f3f7a7fb83160ee049f2c119908668cb64",
      "new_mode": 33188,
      "new_path": "fs/ext2/xattr.c"
    }
  ]
}