libmnl/example/rtnl-route-dump - only dumping up to table #255?

[hvjunk]

Good day,

 I’m busy looking to develop a C program to do some reporting and adding of 
route tables and rules.
Looking at the libmnl example program rtnl-route-dump.c, I can’t seem to find 
why it only list the tables up to #255.

I picked this up as I had a table 993 (the port used for imaps :). testing 
tables 256, 1023,1024, they don’t show up, but my table #70 & table#80 do show 
up.

Where am I missing that limitation?

Hendrik



signature.asc
Description: Message signed with OpenPGP

Re: [Drbd-dev] [PATCH 28/42] drbd: switch to proc_create_single

[Lars Ellenberg]

On Wed, May 16, 2018 at 11:43:32AM +0200, Christoph Hellwig wrote:
> And stop messing with try_module_get on THIS_MODULE, which doesn't make
> any sense here.

The idea was to increase module count on /proc/drbd access.

If someone holds /proc/drbd open, previously rmmod would
"succeed" in starting the unload, but then block on remove_proc_entry,
leading to a situation where the lsmod does not show drbd anymore,
but /proc/drbd being still there (but no longer accessible).

I'd rather have rmmod fail up front in this case.
And try_module_get() seemed most appropriate.

Lars

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Fri, May 18, 2018 at 11:27:56AM +0200, Florian Westphal wrote:
> Greg Kroah-Hartman  wrote:
> > On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > > 
> > > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > > >> > --- a/net/netfilter/x_tables.c
> > > >> > +++ b/net/netfilter/x_tables.c
> > > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info 
> > > >> > *xt_alloc_table_info(unsigned int size)
> > > >> >   * than shoot all processes down before realizing there is 
> > > >> > nothing
> > > >> >   * more to reclaim.
> > > >> >   */
> > > >> > -info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > +info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> >  if (!info)
> > > >> >  return NULL;
> > > >>
> > > >> I am curious, what particular path does not later overwrite the whole 
> > > >> zone ?
> > > >
> > > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > > >can be larger than the size of the structure itself.
> > > >
> > > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > > >and v6, and that's where the "bad data"
> > > 
> > > If the kernel incorrectly copies more bytes than it should, isn't that
> > > a sign that may be going going past the end of the info buffer?
> > > (And thus, zeroing won't truly fix the issue)
> > 
> > No, the buffer size is correct, we just aren't filling up the whole
> > buffer as the data requested is smaller than the buffer size.
> 
> I have no objections to the patch but I'd like to understand what
> problem its fixing.
> 
> Normal pattern is:
> newinfo = xt_alloc_table_info(tmp.size);
> copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
> 
> So inital value of the rule blob area should not matter.
> 
> Furthermore, when copying the rule blob back to userspace,
> the kernel is not supposed to copy any padding back to userspace either,
> since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
> user-relevant parts should be copied (some matches and targets allocate
> kernel-private data such as pointers, and we did use to leak such pointer
> values back to userspace).

Ah, fun, commit f32815d21d4d ("xtables: add xt_match, xt_target and data
copy_to_user functions") showed up in 4.11 and this was reported in 4.4 :(

However, the "bad" code path seems to be from the IPT_SO_GET_ENTRIES
request, which does not look to use the new functions provided in
f32815d21d4d, or am I mistaken?

Let me go work on a reproducer for this to make it a lot more obvious
what is happening, and if it is still even an issue after f32815d21d4d
is applied to a kernel.  Sorry for not providing that in the first
place...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH libmnl] examples: add arp cache dump example

[Pablo Neira Ayuso]

On Thu, May 17, 2018 at 03:10:34PM +0200, Laura Garcia Liebana wrote:
> Adding ARP example in order to dump the info in the form:
> 
> index= family= dst= lladdr= 
> state=

Applied, thanks Laura.

BTW, before applying, I have renamed this to rtnl-neigh-dump instead.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Florian Westphal]

Greg Kroah-Hartman  wrote:
> On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > 
> > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > >> > --- a/net/netfilter/x_tables.c
> > >> > +++ b/net/netfilter/x_tables.c
> > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info 
> > >> > *xt_alloc_table_info(unsigned int size)
> > >> > * than shoot all processes down before realizing there is 
> > >> > nothing
> > >> > * more to reclaim.
> > >> > */
> > >> > -  info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > >> > +  info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > >> >if (!info)
> > >> >return NULL;
> > >>
> > >> I am curious, what particular path does not later overwrite the whole 
> > >> zone ?
> > >
> > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > >can be larger than the size of the structure itself.
> > >
> > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > >and v6, and that's where the "bad data"
> > 
> > If the kernel incorrectly copies more bytes than it should, isn't that
> > a sign that may be going going past the end of the info buffer?
> > (And thus, zeroing won't truly fix the issue)
> 
> No, the buffer size is correct, we just aren't filling up the whole
> buffer as the data requested is smaller than the buffer size.

I have no objections to the patch but I'd like to understand what
problem its fixing.

Normal pattern is:
newinfo = xt_alloc_table_info(tmp.size);
copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);

So inital value of the rule blob area should not matter.

Furthermore, when copying the rule blob back to userspace,
the kernel is not supposed to copy any padding back to userspace either,
since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
user-relevant parts should be copied (some matches and targets allocate
kernel-private data such as pointers, and we did use to leak such pointer
values back to userspace).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 38/42] isdn: replace ->proc_fops with ->proc_show

[Christoph Hellwig]

On Fri, May 18, 2018 at 10:43:46AM +0200, Paul Bolle wrote:
> > iif->ctr.release_appl  = gigaset_release_appl;
> > iif->ctr.send_message  = gigaset_send_message;
> > -   iif->ctr.procinfo  = gigaset_procinfo;
> 
> Is this intentional? You didn't touch the procinfo method in the other ISDN
> drivers, as far as I can see.
> 
> (If it was intentional, gigaset_procinfo() can of course be removed.)

Already fixed in the branch in Als tree.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 38/42] isdn: replace ->proc_fops with ->proc_show

[Paul Bolle]

Hi Christoph,

(I don't think the patches of this series ever hit the ISDN related addresses
still found in MAINTAINERS. And now I might be a bit late.) 

Christoph Hellwig schreef op wo 16-05-2018 om 11:43 [+0200]:
> diff --git a/drivers/isdn/gigaset/capi.c b/drivers/isdn/gigaset/capi.c
> index ccec7778cad2..dac5cd35e901 100644
> --- a/drivers/isdn/gigaset/capi.c
> +++ b/drivers/isdn/gigaset/capi.c
> @@ -2437,19 +2437,6 @@ static int gigaset_proc_show(struct seq_file *m, void 
> *v)
>   return 0;
>  }
>  
> -static int gigaset_proc_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, gigaset_proc_show, PDE_DATA(inode));
> -}
> -
> -static const struct file_operations gigaset_proc_fops = {
> - .owner  = THIS_MODULE,
> - .open   = gigaset_proc_open,
> - .read   = seq_read,
> - .llseek = seq_lseek,
> - .release= single_release,
> -};
> -
>  /**
>   * gigaset_isdn_regdev() - register device to LL
>   * @cs:  device descriptor structure.
> @@ -2478,8 +2465,7 @@ int gigaset_isdn_regdev(struct cardstate *cs, const 
> char *isdnid)
>   iif->ctr.register_appl = gigaset_register_appl;
>   iif->ctr.release_appl  = gigaset_release_appl;
>   iif->ctr.send_message  = gigaset_send_message;
> - iif->ctr.procinfo  = gigaset_procinfo;

Is this intentional? You didn't touch the procinfo method in the other ISDN
drivers, as far as I can see.

(If it was intentional, gigaset_procinfo() can of course be removed.)

> - iif->ctr.proc_fops = _proc_fops;
> + iif->ctr.proc_show = gigaset_proc_show,
>   INIT_LIST_HEAD(>appls);
>   skb_queue_head_init(>sendqueue);
>   atomic_set(>sendqlen, 0);

Thanks,


Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] netfilter: ebtables: handle string from userspace with care

[Pablo Neira Ayuso]

On Fri, Apr 27, 2018 at 10:45:31AM +0200, Paolo Abeni wrote:
> strlcpy() can't be safely used on a user-space provided string,
> as it can try to read beyond the buffer's end, if the latter is
> not NULL terminated.

Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH nft 1/2] Introduce socket matching

[Máté Eckl]

On Thu, May 17, 2018 at 04:42:15PM +0200, Florian Westphal wrote:
> Máté Eckl  wrote:
> > +socket_stmt:   SOCKET  EXISTS /* with the actual 
> > implementation we cannot match abscence */
> 
> I think we should go for a native expression.
> 
> I'll leave it up to you what you'd like to do next.
> There are a few options:
> 1. First go for TPROXY in nft (i.e. finish userspace syntax first)
> 2. add socket expression for nf_tables.
> 3. add support for SYNPROXY (outside of your original proposal,
>but this can be done via nft_compat without loss of functionality).

I think I'll go for option 2.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html