lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZRaFZ4K3ZHTManT7@calendula> Date: Fri, 29 Sep 2023 10:05:59 +0200 From: Pablo Neira Ayuso <pablo@...filter.org> To: Joao Moreira <joao@...rdrivepizza.com> Cc: netfilter-devel@...r.kernel.org, coreteam@...filter.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kadlec@...filter.org, fw@...len.de, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, rkannoth@...vell.com, wojciech.drewek@...el.com, steen.hegenlund@...rohip.com, keescook@...omium.org, Joao Moreira <joao.moreira@...el.com> Subject: Re: [PATCH v3 1/2] Make loop indexes unsigned On Thu, Sep 28, 2023 at 07:53:14PM -0700, Joao Moreira wrote: > On 2023-09-28 06:40, Pablo Neira Ayuso wrote: > > On Wed, Sep 27, 2023 at 09:47:14AM -0700, joao@...rdrivepizza.com wrote: > > > From: Joao Moreira <joao.moreira@...el.com> > > > > > > Both flow_rule_alloc and offload_action_alloc functions received an > > > unsigned num_actions parameters which are then operated within a loop. > > > The index of this loop is declared as a signed int. If it was possible > > > to pass a large enough num_actions to these functions, it would lead > > > to > > > an out of bounds write. > > > > > > After checking with maintainers, it was mentioned that front-end will > > > cap the num_actions value and that it is not possible to reach this > > > function with such a large number. Yet, for correctness, it is still > > > better to fix this. > > > > > > This issue was observed by the commit author while reviewing a > > > write-up > > > regarding a CVE within the same subsystem [1]. > > > > > > 1 - https://nickgregory.me/post/2022/03/12/cve-2022-25636/ > > > > > > Signed-off-by: Joao Moreira <joao.moreira@...el.com> > > > --- > > > net/core/flow_offload.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c > > > index bc5169482710..bc3f53a09d8f 100644 > > > --- a/net/core/flow_offload.c > > > +++ b/net/core/flow_offload.c > > > @@ -10,7 +10,7 @@ > > > struct flow_rule *flow_rule_alloc(unsigned int num_actions) > > > { > > > struct flow_rule *rule; > > > - int i; > > > + unsigned int i; > > > > With the 2^8 cap, I don't think this patch is required anymore. > > Hm. While I understand that there is not a significant menace haunting > this... would it be good for (1) type correctness and (2) prevent that > things blow up if something changes and someone misses this spot? Nothing is going to change, please remove unnecesary updates. Capping to 2^8 for all hardware offload subsystems is sufficient by now. If someone needs more than that, it will have to justify it.
Powered by blists - more mailing lists