ghsa-xp5x-wr7x-fp9j
Vulnerability from github
Published
2024-07-12 15:31
Modified
2024-08-21 18:31
Details

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

netrom: Fix a memory leak in nr_heartbeat_expiry()

syzbot reported a memory leak in nr_create() 0.

Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag.

But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b."

nr_connect nr_establish_data_link nr_start_heartbeat

nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY);

                    nr_rx_frame
                      nr_process_rx_frame
                        switch (nr->state)
                        case NR_STATE_2
                          nr_state2_machine()
                            nr_disconnect()
                              nr_sk(sk)->state = NR_STATE_0
                              sock_set_flag(sk, SOCK_DEAD)

                    nr_heartbeat_expiry
                      switch (nr->state)
                      case NR_STATE_0
                        if (sock_flag(sk, SOCK_DESTROY) ||
                           (sk->sk_state == TCP_LISTEN
                             && sock_flag(sk, SOCK_DEAD)))
                           sock_hold()  // ( !!! )
                           nr_destroy_socket()

To fix the memory leak, let's call sock_hold() only for a listening socket.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.

Show details on source website


{
   affected: [],
   aliases: [
      "CVE-2024-41006",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-401",
      ],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-07-12T13:15:21Z",
      severity: "MODERATE",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: Fix a memory leak in nr_heartbeat_expiry()\n\nsyzbot reported a memory leak in nr_create() [0].\n\nCommit 409db27e3a2e (\"netrom: Fix use-after-free of a listening socket.\")\nadded sock_hold() to the nr_heartbeat_expiry() function, where\na) a socket has a SOCK_DESTROY flag or\nb) a listening socket has a SOCK_DEAD flag.\n\nBut in the case \"a,\" when the SOCK_DESTROY flag is set, the file descriptor\nhas already been closed and the nr_release() function has been called.\nSo it makes no sense to hold the reference count because no one will\ncall another nr_destroy_socket() and put it as in the case \"b.\"\n\nnr_connect\n  nr_establish_data_link\n    nr_start_heartbeat\n\nnr_release\n  switch (nr->state)\n  case NR_STATE_3\n    nr->state = NR_STATE_2\n    sock_set_flag(sk, SOCK_DESTROY);\n\n                        nr_rx_frame\n                          nr_process_rx_frame\n                            switch (nr->state)\n                            case NR_STATE_2\n                              nr_state2_machine()\n                                nr_disconnect()\n                                  nr_sk(sk)->state = NR_STATE_0\n                                  sock_set_flag(sk, SOCK_DEAD)\n\n                        nr_heartbeat_expiry\n                          switch (nr->state)\n                          case NR_STATE_0\n                            if (sock_flag(sk, SOCK_DESTROY) ||\n                               (sk->sk_state == TCP_LISTEN\n                                 && sock_flag(sk, SOCK_DEAD)))\n                               sock_hold()  // ( !!! )\n                               nr_destroy_socket()\n\nTo fix the memory leak, let's call sock_hold() only for a listening socket.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.\n\n[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16",
   id: "GHSA-xp5x-wr7x-fp9j",
   modified: "2024-08-21T18:31:26Z",
   published: "2024-07-12T15:31:30Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-41006",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/0b9130247f3b6a1122478471ff0e014ea96bb735",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/280cf1173726a7059b628c610c71050d5c0b6937",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/5391f9db2cab5ef1cb411be1ab7dbec728078fba",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/a02fd5d775cf9787ee7698c797e20f2fa13d2e2b",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/b6ebe4fed73eedeb73f4540f8edc4871945474c8",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/d377f5a28332954b19e373d36823e59830ab1712",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c5346bc69c",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/e07a9c2a850cdebf625e7a1b8171bd23a8554313",
      },
   ],
   schema_version: "1.4.0",
   severity: [
      {
         score: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
         type: "CVSS_V3",
      },
   ],
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.