)]}'
{
  "commit": "a53357c61ff6b30db5e5f276a72798d1059302e5",
  "tree": "598b9d10eb4bf06f6e8877c9f76a0e45f2f7fb68",
  "parents": [
    "b8303ae58235ecc1ebdf657069ea71a0807914ad"
  ],
  "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": "staging: vme_user: 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: Martyn Welch \u003cmartyn@welchs.me.uk\u003e\nCc: Manohar Vanga \u003cmanohar.vanga@gmail.com\u003e\nCc: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nCc: Soumya Negi \u003csoumya.negi97@gmail.com\u003e\nCc: Alexon Oliveira \u003calexondunkan@gmail.com\u003e\nCc: linux-staging@lists.linux.dev\nSigned-off-by: Kees Cook \u003ckeescook@chromium.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e9461a7a7ab8ba40ed8978134928a5d669f44f5c",
      "old_mode": 33188,
      "old_path": "drivers/staging/vme_user/vme.c",
      "new_id": "a0acf2a295cd4e4936bcbafd12a43742bbf2764a",
      "new_mode": 33188,
      "new_path": "drivers/staging/vme_user/vme.c"
    }
  ]
}