GHSA-C4XM-6JCF-XFQ6

Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2025-01-08 18:30
VLAI?
Details

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

sctp: do asoc update earlier in sctp_sf_do_dupcook_a

There's a panic that occurs in a few of envs, the call trace is as below:

[] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp]

This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire().

Thanks Alexander and Jere for helping dig into this issue.

To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this.

Severity ?
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-46999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T09:15:38Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: do asoc update earlier in sctp_sf_do_dupcook_a\n\nThere\u0027s a panic that occurs in a few of envs, the call trace is as below:\n\n  [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI\n  [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]\n  []  sctp_assoc_control_transport+0x1b9/0x210 [sctp]\n  []  sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]\n  []  sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]\n  []  sctp_do_sm+0xc3/0x2a0 [sctp]\n  []  sctp_generate_timeout_event+0x81/0xf0 [sctp]\n\nThis is caused by a transport use-after-free issue. When processing a\nduplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK\nand SHUTDOWN chunks are allocated with the transort from the new asoc.\nHowever, later in the sideeffect machine, the old asoc is used to send\nthem out and old asoc\u0027s shutdown_last_sent_to is set to the transport\nthat SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually\nbelongs to the new asoc. After the new_asoc is freed and the old asoc\nT2 timeout, the old asoc\u0027s shutdown_last_sent_to that is already freed\nwould be accessed in sctp_sf_t2_timer_expire().\n\nThanks Alexander and Jere for helping dig into this issue.\n\nTo fix it, this patch is to do the asoc update first, then allocate\nthe COOKIE-ACK and SHUTDOWN chunks with the \u0027updated\u0027 old asoc. This\nwould make more sense, as a chunk from an asoc shouldn\u0027t be sent out\nwith another asoc. We had fixed quite a few issues caused by this.",
  "id": "GHSA-c4xm-6jcf-xfq6",
  "modified": "2025-01-08T18:30:40Z",
  "published": "2024-02-28T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46999"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0bfd913c2121b3d553bfd52810fe6061d542d625"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35b4f24415c854cd718ccdf38dbea6297f010aae"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557090a704"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.