CVE-2023-53347
published 2025-09-17CVE-2023-53347: 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…
PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
8.6th percentile
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/0x
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.37-1 (bookworm) | linux 6.1.37-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 04de7dda7394fa9c2b0fc9cec65661d9b4f0d04d < b17294e7aa8c39dbb9c3e28e2d1983c88b94b387 | b17294e7aa8c39dbb9c3e28e2d1983c88b94b387 |
| linux | linux | >= 04de7dda7394fa9c2b0fc9cec65661d9b4f0d04d < 10cbfecc0f99f579fb170feee866c9efaab7ee47 | 10cbfecc0f99f579fb170feee866c9efaab7ee47 |
| linux | linux | >= 04de7dda7394fa9c2b0fc9cec65661d9b4f0d04d < 2be5bd42a5bba1a05daedc86cf0e248210009669 | 2be5bd42a5bba1a05daedc86cf0e248210009669 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.37-1 | 6.1.37-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 5.0 < 6.1.31 | 6.1.31 |
| linux | linux_kernel | >= 6.2 < 6.3.5 | 6.3.5 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: net/mlx5: Handle pairing of E-switch via uplink un/load APIs
vendor_redhat·2025-09-17·CVSS 5.5
CVE-2023-53347 [MEDIUM] CWE-476 kernel: net/mlx5: Handle pairing of E-switch via uplink un/load APIs
kernel: net/mlx5: Handle pairing of E-switch via uplink un/load APIs
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 e
Microsoft
net/mlx5: Handle pairing of E-switch via uplink un/load APIs
vendor_msrc·2025-09-09·CVSS 5.5
CVE-2023-53347 [MEDIUM] net/mlx5: Handle pairing of E-switch via uplink un/load APIs
net/mlx5: Handle pairing of E-switch via uplink un/load APIs
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Debian
CVE-2023-53347: linux - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: H...
vendor_debian·2023·CVSS 5.5
CVE-2023-53347 [MEDIUM] CVE-2023-53347: linux - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: H...
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.
OSV
CVE-2023-53347: 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
osv·2025-09-17·CVSS 5.5
CVE-2023-53347 [MEDIUM] CVE-2023-53347: 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
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.
GHSA
GHSA-52q8-cgf7-57fr: 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
ghsa_unreviewed·2025-09-17
CVE-2023-53347 [MEDIUM] GHSA-52q8-cgf7-57fr: 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
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
f
No detection rules found.
No public exploits indexed.
2025-09-17
Published