)]}'
{
  "commit": "862bee39ef540bd3a7772b899b4fa7f3036abf0d",
  "tree": "2bac0acdffbb15965ef6f291ae7a78c684b768b5",
  "parents": [
    "e9bfcbffb7b26065a2b467e29bb6c7ec83d17646"
  ],
  "author": {
    "name": "Jeff Layton",
    "email": "jlayton@redhat.com",
    "time": "Tue Aug 23 07:21:28 2011 -0400"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@suse.de",
    "time": "Mon Oct 03 11:40:35 2011 -0700"
  },
  "message": "cifs: fix possible memory corruption in CIFSFindNext\n\ncommit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.\n\nThe name_len variable in CIFSFindNext is a signed int that gets set to\nthe resume_name_len in the cifs_search_info. The resume_name_len however\nis unsigned and for some infolevels is populated directly from a 32 bit\nvalue sent by the server.\n\nIf the server sends a very large value for this, then that value could\nlook negative when converted to a signed int. That would make that\nvalue pass the PATH_MAX check later in CIFSFindNext. The name_len would\nthen be used as a length value for a memcpy. It would then be treated\nas unsigned again, and the memcpy scribbles over a ton of memory.\n\nFix this by making the name_len an unsigned value in CIFSFindNext.\n\nReported-by: Darren Lavender \u003cdcl@hppine99.gbr.hp.com\u003e\nSigned-off-by: Jeff Layton \u003cjlayton@redhat.com\u003e\nSigned-off-by: Steve French \u003csfrench@us.ibm.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1a9fe7f816d1b83dd630141412d3dd109b23a385",
      "old_mode": 33188,
      "old_path": "fs/cifs/cifssmb.c",
      "new_id": "07132c4e99f3381faba96d1c436867f0eb8e72ca",
      "new_mode": 33188,
      "new_path": "fs/cifs/cifssmb.c"
    }
  ]
}