| Message ID | 20230901010437.126631-1-joao@overdrivepizza.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Prevent potential write out of bounds | expand |
On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote: > The function flow_rule_alloc in net/core/flow_offload.c [2] gets an > unsigned int num_actions (line 10) and later traverses the actions in > the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE. > > Within the same file, the loop in the line 24 compares a signed int > (i) to an unsigned int (num_actions), and then uses i as an array > index. If an integer overflow happens, then the array within the loop > is wrongly indexed, causing a write out of bounds. > > After checking with maintainers, it seems that the front-end caps the > maximum value of num_action, thus it is not possible to reach the given > write out of bounds, yet, still, to prevent disasters it is better to > fix the signedness here. How did you find this? The commit messages should include info about how the issue was discovered.
On 2023-08-31 18:28, Jakub Kicinski wrote: > On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote: >> The function flow_rule_alloc in net/core/flow_offload.c [2] gets an >> unsigned int num_actions (line 10) and later traverses the actions in >> the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE. >> >> Within the same file, the loop in the line 24 compares a signed int >> (i) to an unsigned int (num_actions), and then uses i as an array >> index. If an integer overflow happens, then the array within the loop >> is wrongly indexed, causing a write out of bounds. >> >> After checking with maintainers, it seems that the front-end caps the >> maximum value of num_action, thus it is not possible to reach the >> given >> write out of bounds, yet, still, to prevent disasters it is better to >> fix the signedness here. > > How did you find this? The commit messages should include info > about how the issue was discovered. Sure, I'll wait a bit longer for more suggestions and add the info in a next patch version. Meanwhile, fwiiw, I stumbled on the bug when I was reading Nick Gregory's write-up on CVE-2022-25636 [1], which happens nearby but is not exactly this issue. Tks, Joao [1] - https://nickgregory.me/post/2022/03/12/cve-2022-25636/
On Thu, Aug 31, 2023 at 06:28:00PM -0700, Jakub Kicinski wrote: > On Thu, 31 Aug 2023 18:04:35 -0700 joao@overdrivepizza.com wrote: > > The function flow_rule_alloc in net/core/flow_offload.c [2] gets an > > unsigned int num_actions (line 10) and later traverses the actions in > > the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE. > > > > Within the same file, the loop in the line 24 compares a signed int > > (i) to an unsigned int (num_actions), and then uses i as an array > > index. If an integer overflow happens, then the array within the loop > > is wrongly indexed, causing a write out of bounds. > > > > After checking with maintainers, it seems that the front-end caps the > > maximum value of num_action, thus it is not possible to reach the given > > write out of bounds, yet, still, to prevent disasters it is better to > > fix the signedness here. > > How did you find this? The commit messages should include info > about how the issue was discovered. This is net-next material IMO, none of the existing interfaces uses such a large number of actions for this to be an issue.
From: Joao Moreira <joao.moreira@intel.com> The function flow_rule_alloc in net/core/flow_offload.c [2] gets an unsigned int num_actions (line 10) and later traverses the actions in the rule (line 24) setting hw.stats to FLOW_ACTION_HW_STATS_DONT_CARE. Within the same file, the loop in the line 24 compares a signed int (i) to an unsigned int (num_actions), and then uses i as an array index. If an integer overflow happens, then the array within the loop is wrongly indexed, causing a write out of bounds. After checking with maintainers, it seems that the front-end caps the maximum value of num_action, thus it is not possible to reach the given write out of bounds, yet, still, to prevent disasters it is better to fix the signedness here. Similarly, also it is also good to ensure that an overflow won't happen in net/netfilter/nf_tables_offload.c's function nft_flow_rule_create by checking that num_actions is not negative. Tks, Joao Moreira (2): Make loop indexes unsigned Ensure num_actions is not a negative net/core/flow_offload.c | 4 ++-- net/netfilter/nf_tables_offload.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)