ghsa-q54v-653w-2v9v
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it.
Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached.
Also the driver never releases the allocated mod hdr actions and causing a memleak.
Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put().
backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]
{ "affected": [], "aliases": [ "CVE-2021-47199" ], "database_specific": { "cwe_ids": [], "github_reviewed": false, "github_reviewed_at": null, "nvd_published_at": "2024-04-10T19:15:48Z", "severity": null }, "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: CT, Fix multiple allocations and memleak of mod acts\n\nCT clear action offload adds additional mod hdr actions to the\nflow\u0027s original mod actions in order to clear the registers which\nhold ct_state.\nWhen such flow also includes encap action, a neigh update event\ncan cause the driver to unoffload the flow and then reoffload it.\n\nEach time this happens, the ct clear handling adds that same set\nof mod hdr actions to reset ct_state until the max of mod hdr\nactions is reached.\n\nAlso the driver never releases the allocated mod hdr actions and\ncausing a memleak.\n\nFix above two issues by moving CT clear mod acts allocation\ninto the parsing actions phase and only use it when offloading the rule.\nThe release of mod acts will be done in the normal flow_put().\n\n backtrace:\n [\u003c000000007316e2f3\u003e] krealloc+0x83/0xd0\n [\u003c00000000ef157de1\u003e] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]\n [\u003c00000000970ce4ae\u003e] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]\n [\u003c0000000067c5fa17\u003e] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]\n [\u003c00000000d032eb98\u003e] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]\n [\u003c00000000fd23b869\u003e] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]\n [\u003c000000004fc24acc\u003e] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]\n [\u003c00000000dc741c17\u003e] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]\n [\u003c00000000e92e49d7\u003e] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]\n [\u003c00000000f60f5602\u003e] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]", "id": "GHSA-q54v-653w-2v9v", "modified": "2024-04-10T21:30:31Z", "published": "2024-04-10T21:30:31Z", "references": [ { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47199" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/486e8de6e233ff2999493533c6259d1cb538653b" }, { "type": "WEB", "url": "https://git.kernel.org/stable/c/806401c20a0f9c51b6c8fd7035671e6ca841f6c2" } ], "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.
- 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.