[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200622082633.GA4512@salvia>
Date: Mon, 22 Jun 2020 10:26:33 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Russell King <rmk+kernel@...linux.org.uk>
Cc: coreteam@...filter.org, netfilter-devel@...r.kernel.org,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] netfiler: ipset: fix unaligned atomic access
On Wed, Jun 10, 2020 at 09:51:11PM +0100, Russell King wrote:
> When using ip_set with counters and comment, traffic causes the kernel
> to panic on 32-bit ARM:
>
> Alignment trap: not handling instruction e1b82f9f at [<bf01b0dc>]
> Unhandled fault: alignment exception (0x221) at 0xea08133c
> PC is at ip_set_match_extensions+0xe0/0x224 [ip_set]
>
> The problem occurs when we try to update the 64-bit counters - the
> faulting address above is not 64-bit aligned. The problem occurs
> due to the way elements are allocated, for example:
>
> set->dsize = ip_set_elem_len(set, tb, 0, 0);
> map = ip_set_alloc(sizeof(*map) + elements * set->dsize);
>
> If the element has a requirement for a member to be 64-bit aligned,
> and set->dsize is not a multiple of 8, but is a multiple of four,
> then every odd numbered elements will be misaligned - and hitting
> an atomic64_add() on that element will cause the kernel to panic.
>
> ip_set_elem_len() must return a size that is rounded to the maximum
> alignment of any extension field stored in the element. This change
> ensures that is the case.
Applied, thanks.
Powered by blists - more mailing lists