ghsa-g922-58r5-qrpv
Vulnerability from github
Published
2024-04-02 09:30
Modified
2024-04-02 09:30
Details

In the Linux kernel, the following vulnerability has been resolved:

blk-iocost: Fix an UBSAN shift-out-of-bounds warning

When iocg_kick_delay() is called from a CPU different than the one which set the delay, @now may be in the past of @iocg->delay_at leading to the following warning:

UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23 shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0x79/0xc0 __ubsan_handle_shift_out_of_bounds+0x2ab/0x300 iocg_kick_delay+0x222/0x230 ioc_rqos_merge+0x1d7/0x2c0 __rq_qos_merge+0x2c/0x80 bio_attempt_back_merge+0x83/0x190 blk_attempt_plug_merge+0x101/0x150 blk_mq_submit_bio+0x2b1/0x720 submit_bio_noacct_nocheck+0x320/0x3e0 __swap_writepage+0x2ab/0x9d0

The underflow itself doesn't really affect the behavior in any meaningful way; however, the past timestamp may exaggerate the delay amount calculated later in the code, which shouldn't be a material problem given the nature of the delay mechanism.

If @now is in the past, this CPU is racing another CPU which recently set up the delay and there's nothing this CPU can contribute w.r.t. the delay. Let's bail early from iocg_kick_delay() in such cases.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2023-52630"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-02T07:15:40Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-iocost: Fix an UBSAN shift-out-of-bounds warning\n\nWhen iocg_kick_delay() is called from a CPU different than the one which set\nthe delay, @now may be in the past of @iocg-\u003edelay_at leading to the\nfollowing warning:\n\n  UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23\n  shift exponent 18446744073709 is too large for 64-bit type \u0027u64\u0027 (aka \u0027unsigned long long\u0027)\n  ...\n  Call Trace:\n   \u003cTASK\u003e\n   dump_stack_lvl+0x79/0xc0\n   __ubsan_handle_shift_out_of_bounds+0x2ab/0x300\n   iocg_kick_delay+0x222/0x230\n   ioc_rqos_merge+0x1d7/0x2c0\n   __rq_qos_merge+0x2c/0x80\n   bio_attempt_back_merge+0x83/0x190\n   blk_attempt_plug_merge+0x101/0x150\n   blk_mq_submit_bio+0x2b1/0x720\n   submit_bio_noacct_nocheck+0x320/0x3e0\n   __swap_writepage+0x2ab/0x9d0\n\nThe underflow itself doesn\u0027t really affect the behavior in any meaningful\nway; however, the past timestamp may exaggerate the delay amount calculated\nlater in the code, which shouldn\u0027t be a material problem given the nature of\nthe delay mechanism.\n\nIf @now is in the past, this CPU is racing another CPU which recently set up\nthe delay and there\u0027s nothing this CPU can contribute w.r.t. the delay.\nLet\u0027s bail early from iocg_kick_delay() in such cases.",
  "id": "GHSA-g922-58r5-qrpv",
  "modified": "2024-04-02T09:30:39Z",
  "published": "2024-04-02T09:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52630"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e4d3f8bd880e02932a9ea179f90bfa74fd2e899"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27b216130e64651e76ed583742a1b4e4d08a67c3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a427b49d02995ea4a6ff93a1432c40fa4d36821"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9f56f38331171c9a19754004f0664686d67ee48d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cd33b330cb21675189e747953845f5c3689e4912"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e5dc63f01e027721c29f82069f7e97e2149fa131"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.