ghsa-262x-vpc4-rwc6
Vulnerability from github
Published
2025-05-01 15:31
Modified
2025-05-01 15:31
Details

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

sctp: clear out_curr if all frag chunks of current msg are pruned

A crash was reported by Zhen Chen:

list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70

and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty.

Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this.

This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent().

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2022-49838"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:07Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: clear out_curr if all frag chunks of current msg are pruned\n\nA crash was reported by Zhen Chen:\n\n  list_del corruption, ffffa035ddf01c18-\u003enext is NULL\n  WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0\n  RIP: 0010:__list_del_entry_valid+0x59/0xe0\n  Call Trace:\n   sctp_sched_dequeue_common+0x17/0x70 [sctp]\n   sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]\n   sctp_outq_flush_data+0x85/0x360 [sctp]\n   sctp_outq_uncork+0x77/0xa0 [sctp]\n   sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]\n   sctp_side_effects+0x37/0xe0 [sctp]\n   sctp_do_sm+0xd0/0x230 [sctp]\n   sctp_primitive_SEND+0x2f/0x40 [sctp]\n   sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]\n   sctp_sendmsg+0x3d5/0x440 [sctp]\n   sock_sendmsg+0x5b/0x70\n\nand in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream\nout_curr outq while this outq was empty.\n\nNormally stream-\u003eout_curr must be set to NULL once all frag chunks of\ncurrent msg are dequeued, as we can see in sctp_sched_dequeue_done().\nHowever, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,\nsctp_sched_dequeue_done() is not called to do this.\n\nThis patch is to fix it by simply setting out_curr to NULL when the\nlast frag chunk of current msg is dequeued from out_curr stream in\nsctp_prsctp_prune_unsent().",
  "id": "GHSA-262x-vpc4-rwc6",
  "modified": "2025-05-01T15:31:49Z",
  "published": "2025-05-01T15:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49838"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2ea600b598dd3e061854dd4dd5b4c815397dfcea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f201ae14ae0f91dbf1cffea7bb1e29e81d4d108"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3eff34e01062ec08fbb45ce2baaaa644550be821"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e27458b18b35caee4b27b37a4a9c503b93cae5cc"
    }
  ],
  "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.


Loading…

Loading…