ghsa-2wjh-rvr2-xxjw
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: Fix chain template offload
When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter.
However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2].
Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one.
As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains.
[1]
unreferenced object 0xffff888107e28800 (size 2048):
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
hex dump (first 32 bytes):
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
backtrace:
[
[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26669"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:43Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: flower: Fix chain template offload\n\nWhen a qdisc is deleted from a net device the stack instructs the\nunderlying driver to remove its flow offload callback from the\nassociated filter block using the \u0027FLOW_BLOCK_UNBIND\u0027 command. The stack\nthen continues to replay the removal of the filters in the block for\nthis driver by iterating over the chains in the block and invoking the\n\u0027reoffload\u0027 operation of the classifier being used. In turn, the\nclassifier in its \u0027reoffload\u0027 operation prepares and emits a\n\u0027FLOW_CLS_DESTROY\u0027 command for each filter.\n\nHowever, the stack does not do the same for chain templates and the\nunderlying driver never receives a \u0027FLOW_CLS_TMPLT_DESTROY\u0027 command when\na qdisc is deleted. This results in a memory leak [1] which can be\nreproduced using [2].\n\nFix by introducing a \u0027tmplt_reoffload\u0027 operation and have the stack\ninvoke it with the appropriate arguments as part of the replay.\nImplement the operation in the sole classifier that supports chain\ntemplates (flower) by emitting the \u0027FLOW_CLS_TMPLT_{CREATE,DESTROY}\u0027\ncommand based on whether a flow offload callback is being bound to a\nfilter block or being unbound from one.\n\nAs far as I can tell, the issue happens since cited commit which\nreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()\nin __tcf_block_put(). The order cannot be reversed as the filter block\nis expected to be freed after flushing all the chains.\n\n[1]\nunreferenced object 0xffff888107e28800 (size 2048):\n comm \"tc\", pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......\n 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................\n backtrace:\n [\u003cffffffff81c06a68\u003e] __kmem_cache_alloc_node+0x1e8/0x320\n [\u003cffffffff81ab374e\u003e] __kmalloc+0x4e/0x90\n [\u003cffffffff832aec6d\u003e] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0\n [\u003cffffffff832bc195\u003e] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u003cffffffff832b2e1a\u003e] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u003cffffffff83a10613\u003e] tc_setup_cb_call+0x183/0x340\n [\u003cffffffff83a9f85a\u003e] fl_tmplt_create+0x3da/0x4c0\n [\u003cffffffff83a22435\u003e] tc_ctl_chain+0xa15/0x1170\n [\u003cffffffff838a863c\u003e] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u003cffffffff83ac87f0\u003e] netlink_rcv_skb+0x170/0x440\n [\u003cffffffff83ac6270\u003e] netlink_unicast+0x540/0x820\n [\u003cffffffff83ac6e28\u003e] netlink_sendmsg+0x8d8/0xda0\n [\u003cffffffff83793def\u003e] ____sys_sendmsg+0x30f/0xa80\n [\u003cffffffff8379d29a\u003e] ___sys_sendmsg+0x13a/0x1e0\n [\u003cffffffff8379d50c\u003e] __sys_sendmsg+0x11c/0x1f0\n [\u003cffffffff843b9ce0\u003e] do_syscall_64+0x40/0xe0\nunreferenced object 0xffff88816d2c0400 (size 1024):\n comm \"tc\", pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....\n 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....\n backtrace:\n [\u003cffffffff81c06a68\u003e] __kmem_cache_alloc_node+0x1e8/0x320\n [\u003cffffffff81ab36c1\u003e] __kmalloc_node+0x51/0x90\n [\u003cffffffff81a8ed96\u003e] kvmalloc_node+0xa6/0x1f0\n [\u003cffffffff82827d03\u003e] bucket_table_alloc.isra.0+0x83/0x460\n [\u003cffffffff82828d2b\u003e] rhashtable_init+0x43b/0x7c0\n [\u003cffffffff832aed48\u003e] mlxsw_sp_acl_ruleset_get+0x428/0x7a0\n [\u003cffffffff832bc195\u003e] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u003cffffffff832b2e1a\u003e] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u003cffffffff83a10613\u003e] tc_setup_cb_call+0x183/0x340\n [\u003cffffffff83a9f85a\u003e] fl_tmplt_create+0x3da/0x4c0\n [\u003cffffffff83a22435\u003e] tc_ctl_chain+0xa15/0x1170\n [\u003cffffffff838a863c\u003e] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u003cffffffff83ac87f0\u003e] netlink_rcv_skb+0x170/0x440\n [\u003cffffffff83ac6270\u003e] netlink_unicast+0x540/0x820\n [\u003cffffffff83ac6e28\u003e] netlink_sendmsg+0x8d8/0xda0\n [\u003cffffffff83793def\u003e] ____sys_sendmsg+0x30f/0xa80\n\n[2]\n # tc qdisc add dev swp1 clsact\n # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32\n # tc qdisc del dev\n---truncated---",
"id": "GHSA-2wjh-rvr2-xxjw",
"modified": "2024-04-02T09:30:41Z",
"published": "2024-04-02T09:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26669"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01"
}
],
"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.