ghsa-52q8-cgf7-57fr
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Handle pairing of E-switch via uplink un/load APIs
In case user switch a device from switchdev mode to legacy mode, mlx5 first unpair the E-switch and afterwards unload the uplink vport. From the other hand, in case user remove or reload a device, mlx5 first unload the uplink vport and afterwards unpair the E-switch.
The latter is causing a bug[1], hence, handle pairing of E-switch as part of uplink un/load APIs.
[1] In case VF_LAG is used, every tc fdb flow is duplicated to the peer esw. However, the original esw keeps a pointer to this duplicated flow, not the peer esw. e.g.: if user create tc fdb flow over esw0, the flow is duplicated over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated flow. During module unload while a peer tc fdb flow is still offloaded, in case the first device to be removed is the peer device (esw1 in the example above), the peer net-dev is destroyed, and so the mlx5e_priv is memset to 0. Afterwards, the peer device is trying to unpair himself from the original device (esw0 in the example above). Unpair API invoke the original device to clear peer flow from its eswitch (esw0), but the peer flow, which is stored over the original eswitch (esw0), is trying to use the peer mlx5e_priv, which is memset to 0 and result in bellow kernel-oops.
[ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60 [ 157.964662 ] #PF: supervisor read access in kernel mode [ 157.965123 ] #PF: error_code(0x0000) - not-present page [ 157.965582 ] PGD 0 P4D 0 [ 157.965866 ] Oops: 0000 [#1] SMP [ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core] [ 157.976164 ] Call Trace: [ 157.976437 ] [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core] [ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core] [ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core] [ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core] [ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core] [ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core] [ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core] [ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core] [ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core] [ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core] [ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core] [ 157.988549 ] pci_device_remove+0x31/0xa0 [ 157.988933 ] device_release_driver_internal+0x18f/0x1f0 [ 157.989402 ] driver_detach+0x3f/0x80 [ 157.989754 ] bus_remove_driver+0x70/0xf0 [ 157.990129 ] pci_unregister_driver+0x34/0x90 [ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core] [ 157.990972 ] __x64_sys_delete_module+0x15a/0x250 [ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110 [ 157.991840 ] do_syscall_64+0x3d/0x90 [ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0
{
"affected": [],
"aliases": [
"CVE-2023-53347"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:38Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Handle pairing of E-switch via uplink un/load APIs\n\nIn case user switch a device from switchdev mode to legacy mode, mlx5\nfirst unpair the E-switch and afterwards unload the uplink vport.\nFrom the other hand, in case user remove or reload a device, mlx5\nfirst unload the uplink vport and afterwards unpair the E-switch.\n\nThe latter is causing a bug[1], hence, handle pairing of E-switch as\npart of uplink un/load APIs.\n\n[1]\nIn case VF_LAG is used, every tc fdb flow is duplicated to the peer\nesw. However, the original esw keeps a pointer to this duplicated\nflow, not the peer esw.\ne.g.: if user create tc fdb flow over esw0, the flow is duplicated\nover esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated\nflow.\nDuring module unload while a peer tc fdb flow is still offloaded, in\ncase the first device to be removed is the peer device (esw1 in the\nexample above), the peer net-dev is destroyed, and so the mlx5e_priv\nis memset to 0.\nAfterwards, the peer device is trying to unpair himself from the\noriginal device (esw0 in the example above). Unpair API invoke the\noriginal device to clear peer flow from its eswitch (esw0), but the\npeer flow, which is stored over the original eswitch (esw0), is\ntrying to use the peer mlx5e_priv, which is memset to 0 and result in\nbellow kernel-oops.\n\n[ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60\n[ 157.964662 ] #PF: supervisor read access in kernel mode\n[ 157.965123 ] #PF: error_code(0x0000) - not-present page\n[ 157.965582 ] PGD 0 P4D 0\n[ 157.965866 ] Oops: 0000 [#1] SMP\n[ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core]\n[ 157.976164 ] Call Trace:\n[ 157.976437 ] \u003cTASK\u003e\n[ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core]\n[ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core]\n[ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core]\n[ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core]\n[ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core]\n[ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core]\n[ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core]\n[ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core]\n[ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core]\n[ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core]\n[ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core]\n[ 157.988549 ] pci_device_remove+0x31/0xa0\n[ 157.988933 ] device_release_driver_internal+0x18f/0x1f0\n[ 157.989402 ] driver_detach+0x3f/0x80\n[ 157.989754 ] bus_remove_driver+0x70/0xf0\n[ 157.990129 ] pci_unregister_driver+0x34/0x90\n[ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core]\n[ 157.990972 ] __x64_sys_delete_module+0x15a/0x250\n[ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110\n[ 157.991840 ] do_syscall_64+0x3d/0x90\n[ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0",
"id": "GHSA-52q8-cgf7-57fr",
"modified": "2025-09-17T15:30:38Z",
"published": "2025-09-17T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53347"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10cbfecc0f99f579fb170feee866c9efaab7ee47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2be5bd42a5bba1a05daedc86cf0e248210009669"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b17294e7aa8c39dbb9c3e28e2d1983c88b94b387"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.