)]}'
{
  "commit": "0f751e641a71157aa584c2a2e22fda52b52b8a56",
  "tree": "53bc2e3edf25f4564376d2dac79a5bfbd1e16bf5",
  "parents": [
    "32001d6fe9ac6b0423e674a3093aa56740849f3b"
  ],
  "author": {
    "name": "Tyler Hicks",
    "email": "tyhicks@canonical.com",
    "time": "Wed Nov 23 11:31:24 2011 -0600"
  },
  "committer": {
    "name": "Tyler Hicks",
    "email": "tyhicks@canonical.com",
    "time": "Wed Nov 23 15:43:53 2011 -0600"
  },
  "message": "eCryptfs: Extend array bounds for all filename chars\n\nFrom mhalcrow\u0027s original commit message:\n\n    Characters with ASCII values greater than the size of\n    filename_rev_map[] are valid filename characters.\n    ecryptfs_decode_from_filename() will access kernel memory beyond\n    that array, and ecryptfs_parse_tag_70_packet() will then decrypt\n    those characters. The attacker, using the FNEK of the crafted file,\n    can then re-encrypt the characters to reveal the kernel memory past\n    the end of the filename_rev_map[] array. I expect low security\n    impact since this array is statically allocated in the text area,\n    and the amount of memory past the array that is accessible is\n    limited by the largest possible ASCII filename character.\n\nThis patch solves the issue reported by mhalcrow but with an\nimplementation suggested by Linus to simply extend the length of\nfilename_rev_map[] to 256. Characters greater than 0x7A are mapped to\n0x00, which is how invalid characters less than 0x7A were previously\nbeing handled.\n\nSigned-off-by: Tyler Hicks \u003ctyhicks@canonical.com\u003e\nReported-by: Michael Halcrow \u003cmhalcrow@google.com\u003e\nCc: stable@kernel.org\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "203a1fdff666911d0d49926c3fab30db3146993b",
      "old_mode": 33188,
      "old_path": "fs/ecryptfs/crypto.c",
      "new_id": "2a834255c75de911b7e1f8eb10026972913e14b4",
      "new_mode": 33188,
      "new_path": "fs/ecryptfs/crypto.c"
    }
  ]
}