{
  "schema_version": "1.4.0",
  "id": "GHSA-52q8-cgf7-57fr",
  "modified": "2025-09-17T15:30:38Z",
  "published": "2025-09-17T15:30:38Z",
  "aliases": [
    "CVE-2023-53347"
  ],
  "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 ]  <TASK>\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",
  "severity": [],
  "affected": [],
  "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"
    }
  ],
  "database_specific": {
    "cwe_ids": [],
    "severity": null,
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-17T15:15:38Z"
  }
}