cve-2024-53124
Vulnerability from cvelistv5
Published
2024-12-02 13:44
Modified
2024-12-02 13:44
Severity ?
Summary
net: fix data-races around sk->sk_forward_alloc
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cbPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6Patch
Impacted products
Vendor Product Version
Linux Linux Version: 4.4
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/dccp/ipv6.c",
            "net/ipv6/tcp_ipv6.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d285eb9d0641",
              "status": "affected",
              "version": "e994b2f0fb92",
              "versionType": "git"
            },
            {
              "lessThan": "073d89808c06",
              "status": "affected",
              "version": "e994b2f0fb92",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/dccp/ipv6.c",
            "net/ipv6/tcp_ipv6.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.4"
            },
            {
              "lessThan": "4.4",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix data-races around sk-\u003esk_forward_alloc\n\nSyzkaller reported this warning:\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0\n Modules linked in:\n CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:inet_sock_destruct+0x1c5/0x1e0\n Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 \u003c0f\u003e 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00\n RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206\n RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007\n RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00\n RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007\n R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00\n R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78\n FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u003cTASK\u003e\n  ? __warn+0x88/0x130\n  ? inet_sock_destruct+0x1c5/0x1e0\n  ? report_bug+0x18e/0x1a0\n  ? handle_bug+0x53/0x90\n  ? exc_invalid_op+0x18/0x70\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? inet_sock_destruct+0x1c5/0x1e0\n  __sk_destruct+0x2a/0x200\n  rcu_do_batch+0x1aa/0x530\n  ? rcu_do_batch+0x13b/0x530\n  rcu_core+0x159/0x2f0\n  handle_softirqs+0xd3/0x2b0\n  ? __pfx_smpboot_thread_fn+0x10/0x10\n  run_ksoftirqd+0x25/0x30\n  smpboot_thread_fn+0xdd/0x1d0\n  kthread+0xd3/0x100\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x34/0x50\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n\nIts possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()\nconcurrently when sk-\u003esk_state == TCP_LISTEN with sk-\u003esk_lock unlocked,\nwhich triggers a data-race around sk-\u003esk_forward_alloc:\ntcp_v6_rcv\n    tcp_v6_do_rcv\n        skb_clone_and_charge_r\n            sk_rmem_schedule\n                __sk_mem_schedule\n                    sk_forward_alloc_add()\n            skb_set_owner_r\n                sk_mem_charge\n                    sk_forward_alloc_add()\n        __kfree_skb\n            skb_release_all\n                skb_release_head_state\n                    sock_rfree\n                        sk_mem_uncharge\n                            sk_forward_alloc_add()\n                            sk_mem_reclaim\n                                // set local var reclaimable\n                                __sk_mem_reclaim\n                                    sk_forward_alloc_add()\n\nIn this syzkaller testcase, two threads call\ntcp_v6_do_rcv() with skb-\u003etruesize=768, the sk_forward_alloc changes like\nthis:\n (cpu 1)             | (cpu 2)             | sk_forward_alloc\n ...                 | ...                 | 0\n __sk_mem_schedule() |                     | +4096 = 4096\n                     | __sk_mem_schedule() | +4096 = 8192\n sk_mem_charge()     |                     | -768  = 7424\n                     | sk_mem_charge()     | -768  = 6656\n ...                 |    ...              |\n sk_mem_uncharge()   |                     | +768  = 7424\n reclaimable=7424    |                     |\n                     | sk_mem_uncharge()   | +768  = 8192\n                     | reclaimable=8192    |\n __sk_mem_reclaim()  |                     | -4096 = 4096\n                     | __sk_mem_reclaim()  | -8192 = -4096 != 0\n\nThe skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when\nsk-\u003esk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().\nFix the same issue in dccp_v6_do_rcv()."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-02T13:44:54.257Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6"
        },
        {
          "url": "https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb"
        }
      ],
      "title": "net: fix data-races around sk-\u003esk_forward_alloc",
      "x_generator": {
        "engine": "bippy-8e903de6a542"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-53124",
    "datePublished": "2024-12-02T13:44:54.257Z",
    "dateReserved": "2024-11-19T17:17:24.995Z",
    "dateUpdated": "2024-12-02T13:44:54.257Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-53124\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-02T14:15:13.220\",\"lastModified\":\"2024-12-11T21:18:59.720\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnet: fix data-races around sk-\u003esk_forward_alloc\\n\\nSyzkaller reported this warning:\\n ------------[ cut here ]------------\\n WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0\\n Modules linked in:\\n CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26\\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\\n RIP: 0010:inet_sock_destruct+0x1c5/0x1e0\\n Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 \u003c0f\u003e 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00\\n RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206\\n RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007\\n RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00\\n RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007\\n R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00\\n R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78\\n FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000\\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\n CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0\\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\\n Call Trace:\\n  \u003cTASK\u003e\\n  ? __warn+0x88/0x130\\n  ? inet_sock_destruct+0x1c5/0x1e0\\n  ? report_bug+0x18e/0x1a0\\n  ? handle_bug+0x53/0x90\\n  ? exc_invalid_op+0x18/0x70\\n  ? asm_exc_invalid_op+0x1a/0x20\\n  ? inet_sock_destruct+0x1c5/0x1e0\\n  __sk_destruct+0x2a/0x200\\n  rcu_do_batch+0x1aa/0x530\\n  ? rcu_do_batch+0x13b/0x530\\n  rcu_core+0x159/0x2f0\\n  handle_softirqs+0xd3/0x2b0\\n  ? __pfx_smpboot_thread_fn+0x10/0x10\\n  run_ksoftirqd+0x25/0x30\\n  smpboot_thread_fn+0xdd/0x1d0\\n  kthread+0xd3/0x100\\n  ? __pfx_kthread+0x10/0x10\\n  ret_from_fork+0x34/0x50\\n  ? __pfx_kthread+0x10/0x10\\n  ret_from_fork_asm+0x1a/0x30\\n  \u003c/TASK\u003e\\n ---[ end trace 0000000000000000 ]---\\n\\nIts possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()\\nconcurrently when sk-\u003esk_state == TCP_LISTEN with sk-\u003esk_lock unlocked,\\nwhich triggers a data-race around sk-\u003esk_forward_alloc:\\ntcp_v6_rcv\\n    tcp_v6_do_rcv\\n        skb_clone_and_charge_r\\n            sk_rmem_schedule\\n                __sk_mem_schedule\\n                    sk_forward_alloc_add()\\n            skb_set_owner_r\\n                sk_mem_charge\\n                    sk_forward_alloc_add()\\n        __kfree_skb\\n            skb_release_all\\n                skb_release_head_state\\n                    sock_rfree\\n                        sk_mem_uncharge\\n                            sk_forward_alloc_add()\\n                            sk_mem_reclaim\\n                                // set local var reclaimable\\n                                __sk_mem_reclaim\\n                                    sk_forward_alloc_add()\\n\\nIn this syzkaller testcase, two threads call\\ntcp_v6_do_rcv() with skb-\u003etruesize=768, the sk_forward_alloc changes like\\nthis:\\n (cpu 1)             | (cpu 2)             | sk_forward_alloc\\n ...                 | ...                 | 0\\n __sk_mem_schedule() |                     | +4096 = 4096\\n                     | __sk_mem_schedule() | +4096 = 8192\\n sk_mem_charge()     |                     | -768  = 7424\\n                     | sk_mem_charge()     | -768  = 6656\\n ...                 |    ...              |\\n sk_mem_uncharge()   |                     | +768  = 7424\\n reclaimable=7424    |                     |\\n                     | sk_mem_uncharge()   | +768  = 8192\\n                     | reclaimable=8192    |\\n __sk_mem_reclaim()  |                     | -4096 = 4096\\n                     | __sk_mem_reclaim()  | -8192 = -4096 != 0\\n\\nThe skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when\\nsk-\u003esk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().\\nFix the same issue in dccp_v6_do_rcv().\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix data-races around sk-\u0026gt;sk_forward_alloc Syzkaller inform\u00f3 esta advertencia: ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 0 PID: 16 en net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 M\u00f3dulos vinculados: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 No contaminado 6.12.0-rc5 #26 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 C\u00f3digo: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 \u0026lt;0f\u0026gt; 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas:  ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30  ---[ fin del seguimiento 000000000000000 ]--- Es posible que dos subprocesos llamen a tcp_v6_do_rcv()/sk_forward_alloc_add() simult\u00e1neamente cuando sk-\u0026gt;sk_state == TCP_LISTEN con sk-\u0026gt;sk_lock desbloqueado, lo que desencadena una carrera de datos alrededor de sk-\u0026gt;sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // establecer variable local recuperable __sk_mem_reclaim sk_forward_alloc_add() En este caso de prueba de syzkaller, dos subprocesos llaman a tcp_v6_do_rcv() con skb-\u0026gt;truesize=768, sk_forward_alloc cambia de esta manera: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 recuperable=7424 | | | sk_mem_uncharge() | +768 = 8192 | recuperable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 No se debe llamar a skb_clone_and_charge_r() en tcp_v6_do_rcv() cuando sk-\u0026gt;sk_state es TCP_LISTEN, esto sucede m\u00e1s adelante en tcp_v6_syn_recv_sock(). Corrija el mismo problema en dccp_v6_do_rcv().\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":4.7,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-362\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.4\",\"versionEndExcluding\":\"6.11.10\",\"matchCriteriaId\":\"BAAC4539-72AA-4F8F-8CEB-AFAC1E1348A9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3C95E234-D335-4B6C-96BF-E2CEBD8654ED\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"E0F717D8-3014-4F84-8086-0124B2111379\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"24DBE6C7-2AAE-4818-AED2-E131F153D2FA\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"24B88717-53F5-42AA-9B72-14C707639E3F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc7:*:*:*:*:*:*\",\"matchCriteriaId\":\"1EF8CD82-1EAE-4254-9545-F85AB94CF90F\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


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 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.