fkie_cve-2023-53347
Vulnerability from fkie_nvd
Published
2025-09-17 15:15
Modified
2025-09-18 13:43
Severity ?
Summary
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 ] <TASK>
[ 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
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "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": "CVE-2023-53347", "lastModified": "2025-09-18T13:43:34.310", "metrics": {}, "published": "2025-09-17T15:15:38.603", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/10cbfecc0f99f579fb170feee866c9efaab7ee47" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2be5bd42a5bba1a05daedc86cf0e248210009669" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/b17294e7aa8c39dbb9c3e28e2d1983c88b94b387" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
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.
- 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.
Loading…
Loading…