{
  "threat_severity" : "Low",
  "public_date" : "2024-06-20T00:00:00Z",
  "bugzilla" : {
    "description" : "kernel: USB: core: Fix hang in usb_kill_urb by adding memory barriers",
    "id" : "2293377",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2293377"
  },
  "cvss3" : {
    "cvss3_base_score" : "4.1",
    "cvss3_scoring_vector" : "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
    "status" : "verified"
  },
  "cwe" : "CWE-820",
  "details" : [ "In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return.  It turns out the issue is not unlinking\nthe URB; that works just fine.  Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\nThe reason is memory-access ordering on SMP systems.  In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\nCPU 0CPU 1\n-------------------------------------------------------------\nusb_kill_urb():__usb_hcd_giveback_urb():\n...  ...\natomic_inc(&urb->reject);  atomic_dec(&urb->use_count);\n...  ...\nwait_event(usb_kill_urb_queue,\natomic_read(&urb->use_count) == 0);\nif (atomic_read(&urb->reject))\nwake_up(&usb_kill_urb_queue);\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\nwrite urb->reject, then read urb->use_count;\nwhereas the overall pattern of accesses on CPU 1 is:\nwrite urb->use_count, then read urb->reject.\nThis pattern is referred to in memory-model circles as SB (for \"Store\nBuffering\"), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes.  The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb->use_count while CPU 1 sees the old\nun-incremented value of urb->reject.  Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\nThe problem is fixed by adding suitable memory barriers.  To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs.  The atomic_inc() and atomic_dec() accesses\nthemselves don't provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\nThis patch adds the necessary memory barriers." ],
  "affected_release" : [ {
    "product_name" : "Red Hat Enterprise Linux 8",
    "release_date" : "2024-09-24T00:00:00Z",
    "advisory" : "RHSA-2024:7001",
    "cpe" : "cpe:/a:redhat:enterprise_linux:8::nfv",
    "package" : "kernel-rt-0:4.18.0-553.22.1.rt7.363.el8_10"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "release_date" : "2024-09-24T00:00:00Z",
    "advisory" : "RHSA-2024:7000",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8",
    "package" : "kernel-0:4.18.0-553.22.1.el8_10"
  } ],
  "package_state" : [ {
    "product_name" : "Red Hat Enterprise Linux 6",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:6"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2022-48760\nhttps://nvd.nist.gov/vuln/detail/CVE-2022-48760\nhttps://lore.kernel.org/linux-cve-announce/2024062008-CVE-2022-48760-b80e@gregkh/T" ],
  "name" : "CVE-2022-48760",
  "csaw" : false
}