)]}'
{
  "commit": "b8303ae58235ecc1ebdf657069ea71a0807914ad",
  "tree": "4067e4fc92dc918de7eb6c3a05096223c3e13d55",
  "parents": [
    "38275658d2c28f4d44e3c62690b4fa595f002e46"
  ],
  "author": {
    "name": "Kees Cook",
    "email": "keescook@chromium.org",
    "time": "Wed Jan 17 16:40:03 2024 -0800"
  },
  "committer": {
    "name": "Kees Cook",
    "email": "keescook@chromium.org",
    "time": "Mon Jan 22 15:47:04 2024 -0800"
  },
  "message": "mm/vmalloc: Refactor intentional wrap-around test\n\nIn an effort to separate intentional arithmetic wrap-around from\nunexpected wrap-around, we need to refactor places that depend on this\nkind of math. One of the most common code patterns of this is:\n\n\tVAR + value \u003c VAR\n\nNotably, this is considered \"undefined behavior\" for signed and pointer\ntypes, which the kernel works around by using the -fno-strict-overflow\noption in the build[1] (which used to just be -fwrapv). Regardless, we\nwant to get the kernel source to the position where we can meaningfully\ninstrument arithmetic wrap-around conditions and catch them when they\nare unexpected, regardless of whether they are signed[2], unsigned[3],\nor pointer[4] types.\n\nRefactor open-coded wrap-around addition test to use add_would_overflow().\nThis paves the way to enabling the wrap-around sanitizers in the future.\n\nLink: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1]\nLink: https://github.com/KSPP/linux/issues/26 [2]\nLink: https://github.com/KSPP/linux/issues/27 [3]\nLink: https://github.com/KSPP/linux/issues/344 [4]\nCc: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nCc: Uladzislau Rezki \u003curezki@gmail.com\u003e\nCc: Christoph Hellwig \u003chch@infradead.org\u003e\nCc: Lorenzo Stoakes \u003clstoakes@gmail.com\u003e\nCc: linux-mm@kvack.org\nSigned-off-by: Kees Cook \u003ckeescook@chromium.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7932ac99e9d37af9b8079b5f9e2f3e9a098a83bd",
      "old_mode": 33188,
      "old_path": "mm/vmalloc.c",
      "new_id": "3d73f2ac6957874fcda7651d88720798141b7163",
      "new_mode": 33188,
      "new_path": "mm/vmalloc.c"
    }
  ]
}