From: Sabrina Dubroca <s...@queasysnail.net>
Date: Wed, 20 May 2020 11:15:46 +0200

> In case we can't find a ->dumpit callback for the requested
> (family,type) pair, we fall back to (PF_UNSPEC,type). In effect, we're
> in the same situation as if userspace had requested a PF_UNSPEC
> dump. For RTM_GETROUTE, that handler is rtnl_dump_all, which calls all
> the registered RTM_GETROUTE handlers.
> 
> The requested table id may or may not exist for all of those
> families. commit ae677bbb4441 ("net: Don't return invalid table id
> error when dumping all families") fixed the problem when userspace
> explicitly requests a PF_UNSPEC dump, but missed the fallback case.
> 
> For example, when we pass ipv6.disable=1 to a kernel with
> CONFIG_IP_MROUTE=y and CONFIG_IP_MROUTE_MULTIPLE_TABLES=y,
> the (PF_INET6, RTM_GETROUTE) handler isn't registered, so we end up in
> rtnl_dump_all, and listing IPv6 routes will unexpectedly print:
> 
>   # ip -6 r
>   Error: ipv4: MR table does not exist.
>   Dump terminated
> 
> commit ae677bbb4441 introduced the dump_all_families variable, which
> gets set when userspace requests a PF_UNSPEC dump. However, we can't
> simply set the family to PF_UNSPEC in rtnetlink_rcv_msg in the
> fallback case to get dump_all_families == true, because some messages
> types (for example RTM_GETRULE and RTM_GETNEIGH) only register the
> PF_UNSPEC handler and use the family to filter in the kernel what is
> dumped to userspace. We would then export more entries, that userspace
> would have to filter. iproute does that, but other programs may not.
> 
> Instead, this patch removes dump_all_families and updates the
> RTM_GETROUTE handlers to check if the family that is being dumped is
> their own. When it's not, which covers both the intentional PF_UNSPEC
> dumps (as dump_all_families did) and the fallback case, ignore the
> missing table id error.
> 
> Fixes: cb167893f41e ("net: Plumb support for filtering ipv4 and ipv6 
> multicast route dumps")
> Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>

Applied and queued up for -stable, thank you.

Reply via email to