)]}'
{
  "commit": "fa84f12c6d738af9486e69a006a57df923f9476a",
  "tree": "0a533abdb36ecc2cf44d9a3c6f43bed9d510e7d4",
  "parents": [
    "7e8a5293f4a62df1dc717093ce6c22cc97b7f1ae"
  ],
  "author": {
    "name": "Daniel Borkmann",
    "email": "daniel@iogearbox.net",
    "time": "Tue Apr 21 14:58:22 2020 +0200"
  },
  "committer": {
    "name": "Vaibhav Rustagi",
    "email": "vaibhavrustagi@google.com",
    "time": "Tue Apr 28 02:21:53 2020 +0000"
  },
  "message": "bpf: fix buggy r0 retval refinement for tracing helpers\n\n[ no upstream commit ]\n\nSee the glory details in 100605035e15 (\"bpf: Verifier, do_refine_retval_range\nmay clamp umin to 0 incorrectly\") for why 849fa50662fb (\"bpf/verifier: refine\nretval R0 state for bpf_get_stack helper\") is buggy. The whole series however\nis not suitable for stable since it adds significant amount [0] of verifier\ncomplexity in order to add 32bit subreg tracking. Something simpler is needed.\n\nUnfortunately, reverting 849fa50662fb (\"bpf/verifier: refine retval R0 state\nfor bpf_get_stack helper\") or just cherry-picking 100605035e15 (\"bpf: Verifier,\ndo_refine_retval_range may clamp umin to 0 incorrectly\") is not an option since\nit will break existing tracing programs badly (at least those that are using\nbpf_get_stack() and bpf_probe_read_str() helpers). Not fixing it in stable is\nalso not an option since on 4.19 kernels an error will cause a soft-lockup due\nto hitting dead-code sanitized branch since we don\u0027t hard-wire such branches\nin old kernels yet. But even then for 5.x 849fa50662fb (\"bpf/verifier: refine\nretval R0 state for bpf_get_stack helper\") would cause wrong bounds on the\nverifier simluation when an error is hit.\n\nIn one of the earlier iterations of mentioned patch series for upstream there\nwas the concern that just using smax_value in do_refine_retval_range() would\nnuke bounds by subsequent \u003c\u003c32 \u003e\u003e32 shifts before the comparison against 0 [1]\nwhich eventually led to the 32bit subreg tracking in the first place. While I\ninitially went for implementing the idea [1] to pattern match the two shift\noperations, it turned out to be more complex than actually needed, meaning, we\ncould simply treat do_refine_retval_range() similarly to how we branch off\nverification for conditionals or under speculation, that is, pushing a new\nreg state to the stack for later verification. This means, instead of verifying\nthe current path with the ret_reg in [S32MIN, msize_max_value] interval where\nlater bounds would get nuked, we split this into two: i) for the success case\nwhere ret_reg can be in [0, msize_max_value], and ii) for the error case with\nret_reg known to be in interval [S32MIN, -1]. Latter will preserve the bounds\nduring these shift patterns and can match reg \u003c 0 test. test_progs also succeed\nwith this approach.\n\n  [0] https://lore.kernel.org/bpf/158507130343.15666.8018068546764556975.stgit@john-Precision-5820-Tower/\n  [1] https://lore.kernel.org/bpf/158015334199.28573.4940395881683556537.stgit@john-XPS-13-9370/T/#m2e0ad1d5949131014748b6daa48a3495e7f0456d\n\nChange-Id: I0f923045aaaaee89fae3508661a61ec105e45863\nFixes: 849fa50662fb (\"bpf/verifier: refine retval R0 state for bpf_get_stack helper\")\nReported-by: Lorenzo Fontana \u003cfontanalorenz@gmail.com\u003e\nReported-by: Leonardo Di Donato \u003cleodidonato@gmail.com\u003e\nReported-by: John Fastabend \u003cjohn.fastabend@gmail.com\u003e\nSigned-off-by: Daniel Borkmann \u003cdaniel@iogearbox.net\u003e\nAcked-by: Alexei Starovoitov \u003cast@kernel.org\u003e\nAcked-by: John Fastabend \u003cjohn.fastabend@gmail.com\u003e\nTested-by: John Fastabend \u003cjohn.fastabend@gmail.com\u003e\nTested-by: Lorenzo Fontana \u003cfontanalorenz@gmail.com\u003e\nTested-by: Leonardo Di Donato \u003cleodidonato@gmail.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n(cherry picked from commit e0b80b7d646646273af0770a2bd4d105719387e3)\n\nSOURCE\u003dUPSTREAM(e0b80b7d646646273af0770a2bd4d105719387e3)\nBUG\u003db/152325301\nTEST\u003dManually verified with repro at b/152325301#comment19\nRELEASE_NOTE\u003dFixed a kernel bug where eBPF programs can cause soft\nlockups\n\nChange-Id: Idfb1d3ed7529d9b06303b1626744f215a7d318d6\nSigned-off-by: Xuewei Zhang \u003cxueweiz@google.com\u003e\nReviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/1361\nReviewed-by: Vaibhav Rustagi \u003cvaibhavrustagi@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e85636fb81b9c2db7d61b0a5755984a71d96fe8b",
      "old_mode": 33188,
      "old_path": "kernel/bpf/verifier.c",
      "new_id": "daf0a9637d73a4b6546b2a8442b20e5ccc445ce2",
      "new_mode": 33188,
      "new_path": "kernel/bpf/verifier.c"
    }
  ]
}