GHSA-QJGQ-7W73-7HVF

Vulnerability from github – Published: 2024-08-22 03:31 – Updated: 2024-09-12 15:32
VLAI
Details

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

xen/netfront: destroy queues before real_num_tx_queues is zeroed

xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that xennet_destroy_queues() called from xennet_remove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes:

BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 52 Comm: xenwatch Tainted: G        W         5.16.10-1.32.fc32.qubes.x86_64+ #226
RIP: 0010:free_netdev+0xa3/0x1a0
Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
FS:  0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
Call Trace:
 <TASK>
 xennet_remove+0x13d/0x300 [xen_netfront]
 xenbus_dev_remove+0x6d/0xf0
 __device_release_driver+0x17a/0x240
 device_release_driver+0x24/0x30
 bus_remove_device+0xd8/0x140
 device_del+0x18b/0x410
 ? _raw_spin_unlock+0x16/0x30
 ? klist_iter_exit+0x14/0x20
 ? xenbus_dev_request_and_reply+0x80/0x80
 device_unregister+0x13/0x60
 xenbus_dev_changed+0x18e/0x1f0
 xenwatch_thread+0xc0/0x1a0
 ? do_wait_intr_irq+0xa0/0xa0
 kthread+0x16b/0x190
 ? set_kthread_struct+0x40/0x40
 ret_from_fork+0x22/0x30
 </TASK>

Fix this by calling xennet_destroy_queues() from xennet_uninit(), when real_num_tx_queues is still available. This ensures that queues are destroyed when real_num_tx_queues is set to 0, regardless of how unregister_netdev() was called.

Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-22T02:15:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen/netfront: destroy queues before real_num_tx_queues is zeroed\n\nxennet_destroy_queues() relies on info-\u003enetdev-\u003ereal_num_tx_queues to\ndelete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5\n(\"net-sysfs: update the queue counts in the unregistration path\"),\nunregister_netdev() indirectly sets real_num_tx_queues to 0. Those two\nfacts together means, that xennet_destroy_queues() called from\nxennet_remove() cannot do its job, because it\u0027s called after\nunregister_netdev(). This results in kfree-ing queues that are still\nlinked in napi, which ultimately crashes:\n\n    BUG: kernel NULL pointer dereference, address: 0000000000000000\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP PTI\n    CPU: 1 PID: 52 Comm: xenwatch Tainted: G        W         5.16.10-1.32.fc32.qubes.x86_64+ #226\n    RIP: 0010:free_netdev+0xa3/0x1a0\n    Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff \u003c48\u003e 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00\n    RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286\n    RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000\n    RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff\n    RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000\n    R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050\n    R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680\n    FS:  0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0\n    Call Trace:\n     \u003cTASK\u003e\n     xennet_remove+0x13d/0x300 [xen_netfront]\n     xenbus_dev_remove+0x6d/0xf0\n     __device_release_driver+0x17a/0x240\n     device_release_driver+0x24/0x30\n     bus_remove_device+0xd8/0x140\n     device_del+0x18b/0x410\n     ? _raw_spin_unlock+0x16/0x30\n     ? klist_iter_exit+0x14/0x20\n     ? xenbus_dev_request_and_reply+0x80/0x80\n     device_unregister+0x13/0x60\n     xenbus_dev_changed+0x18e/0x1f0\n     xenwatch_thread+0xc0/0x1a0\n     ? do_wait_intr_irq+0xa0/0xa0\n     kthread+0x16b/0x190\n     ? set_kthread_struct+0x40/0x40\n     ret_from_fork+0x22/0x30\n     \u003c/TASK\u003e\n\nFix this by calling xennet_destroy_queues() from xennet_uninit(),\nwhen real_num_tx_queues is still available. This ensures that queues are\ndestroyed when real_num_tx_queues is set to 0, regardless of how\nunregister_netdev() was called.\n\nOriginally reported at\nhttps://github.com/QubesOS/qubes-issues/issues/7257",
  "id": "GHSA-qjgq-7w73-7hvf",
  "modified": "2024-09-12T15:32:59Z",
  "published": "2024-08-22T03:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48914"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/198cdc287769c717dafff5887c6125cb7a373bf3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/47e2f166ed9fe17f24561d6315be2228f6a90209"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1753d5c29a6fb9a8966dcf04cb4f3b71e303ae8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a63eb1e4a2e1a191a90217871e67fba42fd39255"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b40c912624775a21da32d1105e158db5f6d0554a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f"
    }
  ],
  "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.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.