)]}'
{
  "commit": "8a23eb804ca4f2be909e372cf5a9e7b30ae476cd",
  "tree": "386f95726621b662371e30771a07b94cbac590f1",
  "parents": [
    "9f79b78ef74436c7507bac6bfb7b8b989263bccb"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sat Oct 05 11:32:52 2019 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sat Oct 05 12:00:36 2019 -0700"
  },
  "message": "Make filldir[64]() verify the directory entry filename is valid\n\nThis has been discussed several times, and now filesystem people are\ntalking about doing it individually at the filesystem layer, so head\nthat off at the pass and just do it in getdents{64}().\n\nThis is partially based on a patch by Jann Horn, but checks for NUL\nbytes as well, and somewhat simplified.\n\nThere\u0027s also commentary about how it might be better if invalid names\ndue to filesystem corruption don\u0027t cause an immediate failure, but only\nan error at the end of the readdir(), so that people can still see the\nfilenames that are ok.\n\nThere\u0027s also been discussion about just how much POSIX strictly speaking\nrequires this since it\u0027s about filesystem corruption.  It\u0027s really more\n\"protect user space from bad behavior\" as pointed out by Jann.  But\nsince Eric Biederman looked up the POSIX wording, here it is for context:\n\n \"From readdir:\n\n   The readdir() function shall return a pointer to a structure\n   representing the directory entry at the current position in the\n   directory stream specified by the argument dirp, and position the\n   directory stream at the next entry. It shall return a null pointer\n   upon reaching the end of the directory stream. The structure dirent\n   defined in the \u003cdirent.h\u003e header describes a directory entry.\n\n  From definitions:\n\n   3.129 Directory Entry (or Link)\n\n   An object that associates a filename with a file. Several directory\n   entries can associate names with the same file.\n\n  ...\n\n   3.169 Filename\n\n   A name consisting of 1 to {NAME_MAX} bytes used to name a file. The\n   characters composing the name may be selected from the set of all\n   character values excluding the slash character and the null byte. The\n   filenames dot and dot-dot have special meaning. A filename is\n   sometimes referred to as a \u0027pathname component\u0027.\"\n\nNote that I didn\u0027t bother adding the checks to any legacy interfaces\nthat nobody uses.\n\nAlso note that if this ends up being noticeable as a performance\nregression, we can fix that to do a much more optimized model that\nchecks for both NUL and \u0027/\u0027 at the same time one word at a time.\n\nWe haven\u0027t really tended to optimize \u0027memchr()\u0027, and it only checks for\none pattern at a time anyway, and we really _should_ check for NUL too\n(but see the comment about \"soft errors\" in the code about why it\ncurrently only checks for \u0027/\u0027)\n\nSee the CONFIG_DCACHE_WORD_ACCESS case of hash_name() for how the name\nlookup code looks for pathname terminating characters in parallel.\n\nLink: https://lore.kernel.org/lkml/20190118161440.220134-2-jannh@google.com/\nCc: Alexander Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Jann Horn \u003cjannh@google.com\u003e\nCc: Eric W. Biederman \u003cebiederm@xmission.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "579c8ea894ae388723ce1c2cdab214c0f0bdb65d",
      "old_mode": 33188,
      "old_path": "fs/readdir.c",
      "new_id": "19bea591c3f1d535f8542be83019334a356cbc2c",
      "new_mode": 33188,
      "new_path": "fs/readdir.c"
    }
  ]
}