On Wed, Jan 16, 2019 at 4:48 PM Phil Sutter wrote:
>
> Content is rather sparse, but still better than no manpage at all.
>
> Cc: Willem de Bruijn
> Signed-off-by: Phil Sutter
Thanks for adding this, Phil.
Content looks great to me. One inline question.
> ---
&g
---
> iptables/iptables.c | 66 +--
> libxtables/xtables.c | 221
+-
> 4 files changed, 257 insertions(+), 102 deletions(-)
> --
For the series:
Acked-by: Willem de Bruijn
Thanks for fixing this, Serhey.
--
To unsubscribe from this list: se
> I see several possible areas of contention:
>
> 1) If you aim for a non-feature-complete support of iptables rules, it
>will create confusion to the users.
Right, you need full feature parity to be avoid ending up having to
maintain two implementations.
It seems uncontroversial that BPF can
On Thu, Nov 30, 2017 at 11:08 PM, Jann Horn wrote:
> On Fri, Dec 1, 2017 at 5:04 AM, Willem de Bruijn
> wrote:
>> On Thu, Nov 30, 2017 at 7:46 PM, Jann Horn wrote:
>>> Check whether inputs from userspace are too long (explicit length field too
>>> big or string not
On Thu, Nov 30, 2017 at 7:46 PM, Jann Horn wrote:
> Check whether inputs from userspace are too long (explicit length field too
> big or string not null-terminated) to avoid out-of-bounds reads.
>
> As far as I can tell, this can at worst lead to very limited kernel heap
> memory disclosure or oop
; immediatley after IPT_SO_GET_ENTRIES, by opening a new,
> process-local fd per every 'xt_bpf_info_v1' entry seen.
>
> However, in [2] both Pablo Neira Ayuso and Willem de Bruijn suggested to
> depricate the xt_bpf_info_v1 ABI dealing with pinned ebpf objects.
>
> This fix ch
On Mon, Sep 18, 2017 at 1:23 PM, Pablo Neira Ayuso wrote:
> On Mon, Sep 18, 2017 at 08:00:42PM +0300, Shmulik Ladkani wrote:
>> Hi Pablo,
>>
>> On Mon, 18 Sep 2017 18:28:11 +0200 Pablo Neira Ayuso
>> wrote:
>>
>> > >
>> > > + /* Fixes the match info after init. */
>> > > + void (*tc_init_fixup)(
ure is being re-open
> in tc_init_fixup which is invoked immediately after tc_init.
>
> Signed-off-by: Rafael Buchbinder
> Signed-off-by: Shmulik Ladkani
Thanks a lot for fixing this.
Acked-by: Willem de Bruijn
The pinned object at that filepath can change between iptables invocat
On Wed, Sep 13, 2017 at 11:05 AM, Willem de Bruijn
wrote:
> On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt wrote:
>>
>> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>>
>>>One way to fix is to have iptables open the object (using the stored
>&g
On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt wrote:
>
> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>
>>One way to fix is to have iptables open the object (using the stored
>>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>>just after getting the rules from IP
On Wed, May 17, 2017 at 1:02 AM, Willem de Bruijn
wrote:
> On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the netfilter tree, today's linux-next build (i386
>> defconfig) failed like this:
>>
>> net/netf
From: Willem de Bruijn
The patch in the Fixes references COMPAT_XT_ALIGN in the definition
of XT_DATA_TO_USER, outside an #ifdef CONFIG_COMPAT block.
Split XT_DATA_TO_USER into separate compat and non compat variants and
define the first inside an CONFIG_COMPAT block.
This simplifies both
On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the netfilter tree, today's linux-next build (i386
> defconfig) failed like this:
>
> net/netfilter/x_tables.c: In function 'xt_match_to_user':
> net/netfilter/x_tables.c:303:13: error: implicit declaration of f
From: Willem de Bruijn
When looking up an iptables rule, the iptables binary compares the
aligned match and target data (XT_ALIGN). In some cases this can
exceed the actual data size to include padding bytes.
Before commit f77bc5b23fb1 ("iptables: use match, target and data
copy_to_user he
On Tue, May 9, 2017 at 12:18 AM, Willem de Bruijn wrote:
> On Mon, May 8, 2017 at 10:22 PM, Willem de Bruijn
> wrote:
>> On Mon, May 8, 2017 at 4:22 PM, Florian Westphal wrote:
>>> Richard Guy Briggs wrote:
>>>
>>> [ CC'ing Willem ]
>>
On Mon, May 8, 2017 at 10:22 PM, Willem de Bruijn
wrote:
> On Mon, May 8, 2017 at 4:22 PM, Florian Westphal wrote:
>> Richard Guy Briggs wrote:
>>
>> [ CC'ing Willem ]
>>
>>> (Summary of IRC conversation for background...)
>>> Paul Moore and
On Mon, May 8, 2017 at 4:22 PM, Florian Westphal wrote:
> Richard Guy Briggs wrote:
>
> [ CC'ing Willem ]
>
>> (Summary of IRC conversation for background...)
>> Paul Moore and I hit what appears to be a bug since f25's 4.10.11 and
>> upstream's 4.11-rc3 that would fail to locate on deletion an i
>> > It may be more subtle than what you describe. xtables_find_match
>> > can call xtables_fully_register_pending_match which calls
>> > compatible_match_revision to decide whether a match revision
>> > is supported and, if multiple revisions are supported, which to prefer.
>>
>> The case reported
On Wed, Apr 26, 2017 at 5:15 PM, Willem de Bruijn
wrote:
>>> The patch breaks backward/forward compatibility in a match/target.
>>>
>>> When the list of the revisions of a given match/target of iptables is not
>>> exactly the same as for the kernel
>> The patch breaks backward/forward compatibility in a match/target.
>>
>> When the list of the revisions of a given match/target of iptables is not
>> exactly the same as for the kernel counter part (when the kernel module
>> supports less revisions than iptables), then in spite of the supported
On Fri, Apr 21, 2017 at 4:15 PM, Jozsef Kadlecsik
wrote:
> Hi,
>
> On Thu, 8 Dec 2016, Willem de Bruijn wrote:
>
>> From: Willem de Bruijn
>>
>> Between revisions, the layout of xtables data may change completely.
>> Do not interpret the data in a re
From: Willem de Bruijn
Convert arptables to copying entries, matches and targets one by one,
using the xt_match_to_user and xt_target_to_user helper functions.
Signed-off-by: Willem de Bruijn
---
net/ipv4/netfilter/arp_tables.c | 15 +--
1 file changed, 5 insertions(+), 10
From: Willem de Bruijn
In matches and targets that define a kernel-only tail to their
xt_match and xt_target data structs, add a field .usersize that
specifies up to where data is to be shared with userspace.
Performed a search for comment "Used internally by the kernel" to fin
From: Willem de Bruijn
Convert ebtables to copying entries, matches and targets one by one.
The solution is analogous to that of generic xt_(match|target)_to_user
helpers, but is applied to different structs.
Convert existing helpers ebt_make_XXXname helpers that overwrite
fields of an already
From: Willem de Bruijn
Convert compat to copying entries, matches and targets one by one,
using the xt_match_to_user and xt_target_to_user helper functions.
Signed-off-by: Willem de Bruijn
---
net/netfilter/x_tables.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff
From: Willem de Bruijn
xtables list and save interfaces share xt_match and xt_target state
with userspace. The kernel and userspace definitions of these structs
differ. Currently, the structs are copied wholesale, then patched up.
The match and target structs contain a kernel pointer. Type
From: Willem de Bruijn
Convert iptables to copying entries, matches and targets one by one,
using the xt_match_to_user and xt_target_to_user helper functions.
Signed-off-by: Willem de Bruijn
---
net/ipv4/netfilter/ip_tables.c | 21 ++---
1 file changed, 6 insertions(+), 15
From: Willem de Bruijn
Convert ip6tables to copying entries, matches and targets one by one,
using the xt_match_to_user and xt_target_to_user helper functions.
Signed-off-by: Willem de Bruijn
---
net/ipv6/netfilter/ip6_tables.c | 21 ++---
1 file changed, 6 insertions(+), 15
From: Willem de Bruijn
xt_entry_target, xt_entry_match and their private data may contain
kernel data.
Introduce helper functions xt_match_to_user, xt_target_to_user and
xt_data_to_user that copy only the expected fields. These replace
existing logic that calls copy_to_user on entire structs
From: Willem de Bruijn
Between revisions, the layout of xtables data may change completely.
Do not interpret the data in a revision M with a module of revision N.
Signed-off-by: Willem de Bruijn
---
iptables/ip6tables.c | 18 ++
iptables/iptables.c | 18 ++
2
From: Willem de Bruijn
Exercise the new kernel feature introduced in commit 2c16d6033264
("netfilter: xt_bpf: support ebpf") to load pinned eBPF programs.
The new interface allows instantiating a bpf match using
-m bpf --object-pinned ${PATH}
where ${PATH} points to a node in a b
On Mon, Dec 5, 2016 at 7:20 PM, Florian Westphal wrote:
> Willem de Bruijn wrote:
>> While we're discussing the patch, another question, about revisions: I
>> tested both modified and original iptables binaries on both standard
>> and modified kernels. It all works a
From: Willem de Bruijn
Add support for attaching an eBPF object by file descriptor.
The iptables binary can be called with a path to an elf object or a
pinned bpf object. Also pass the mode and path to the kernel to be
able to return it later for iptables dump and save.
Signed-off-by: Willem
On Mon, Dec 5, 2016 at 6:29 PM, Willem de Bruijn wrote:
> On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso wrote:
>> On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote:
>> [...]
>>> Eric also suggests a private variable to avoid being subject to
>>
On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso wrote:
> On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote:
> [...]
>> Eric also suggests a private variable to avoid being subject to
>> changes to PATH_MAX. Then we can indeed also choose an arbitrary lower
>
On Mon, Dec 5, 2016 at 6:00 PM, Pablo Neira Ayuso wrote:
> On Mon, Dec 05, 2016 at 11:34:15PM +0100, Pablo Neira Ayuso wrote:
>> On Mon, Dec 05, 2016 at 10:30:01PM +0100, Florian Westphal wrote:
>> > Eric Dumazet wrote:
>> > > On Mon, 2016-12-05 at 15:28
On Mon, Dec 5, 2016 at 5:55 PM, Daniel Borkmann wrote:
> Hi Willem,
>
> On 12/05/2016 09:28 PM, Willem de Bruijn wrote:
>>
>> From: Willem de Bruijn
>>
>> Add support for attaching an eBPF object by file descriptor.
>>
>> The iptables binary ca
From: Willem de Bruijn
Add support for attaching an eBPF object by file descriptor.
The iptables binary can be called with a path to an elf object or a
pinned bpf object. Also pass the mode and path to the kernel to be
able to return it later for iptables dump and save.
Signed-off-by: Willem
From: Willem de Bruijn
The xt_bpf module applies BPF bytecode to the packet. Depending on
where the module is invoked, the kernel may pass a packet with or
without link layer header. Iptables has no such header.
A common `tcpdump -ddd ` compilation command may revert to
a physical device that
39 matches
Mail list logo