commit 99253eb750fd ("ipv6: check sk sk_type and protocol early in
ip_mroute_set/getsockopt") fixed the issue for ip6_mroute_setsockopt()
and ip6_mroute_getsockopt() by checking socket type and protocol
before accessing raw6_sk(sk)->ip6mr_table.

However, ip6mr_ioctl() and ip6mr_compat_ioctl() were missed in that fix
and have the same problem: they access raw6_sk(sk)->ip6mr_table without
first verifying that the socket is a raw socket with IPPROTO_ICMPV6
protocol.

This allows a permission bypass where a user with CAP_NET_RAW can create
a non-ICMPv6 raw socket (e.g., IPPROTO_UDP, IPPROTO_TCP, or any other
protocol) and use SIOCGETMIFCNT_IN6 or SIOCGETSGCNT_IN6 ioctls to query
IPv6 multicast routing statistics. This bypasses the access control that
restricts mroute operations to ICMPv6 sockets only.

For example, the following would succeed on a vulnerable kernel:

    int fd = socket(AF_INET6, SOCK_RAW, IPPROTO_UDP);
    struct sioc_mif_req6 req = { .mifi = 0 };
    ioctl(fd, SIOCGETMIFCNT_IN6, &req);  // should fail with EOPNOTSUPP

While the direct security impact is limited to information disclosure of
multicast routing statistics, this violates the intended access control
model where only ICMPv6 raw sockets should be able to access mroute
functionalities.

Add the same socket type and protocol check at the beginning of both
ip6mr_ioctl() and ip6mr_compat_ioctl() to ensure only ICMPv6 raw sockets
can access multicast routing ioctls.

Fixes: e2d57766e674 ("net: Provide compat support for SIOCGETMIFCNT_IN6 and SIOCGETSGCNT_IN6.")
Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
Signed-off-by: Kery Qi <qikeyu2017@gmail.com>
---
 net/ipv6/ip6mr.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index e047a4680ab0..35f941861008 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1906,6 +1906,10 @@ int ip6mr_ioctl(struct sock *sk, int cmd, void *arg)
 	struct net *net = sock_net(sk);
 	struct mr_table *mrt;
 
+	if (sk->sk_type != SOCK_RAW ||
+	    inet_sk(sk)->inet_num != IPPROTO_ICMPV6)
+		return -EOPNOTSUPP;
+
 	mrt = ip6mr_get_table(net, raw6_sk(sk)->ip6mr_table ? : RT6_TABLE_DFLT);
 	if (!mrt)
 		return -ENOENT;
@@ -1974,6 +1978,10 @@ int ip6mr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
 	struct net *net = sock_net(sk);
 	struct mr_table *mrt;
 
+	if (sk->sk_type != SOCK_RAW ||
+	    inet_sk(sk)->inet_num != IPPROTO_ICMPV6)
+		return -EOPNOTSUPP;
+
 	mrt = ip6mr_get_table(net, raw6_sk(sk)->ip6mr_table ? : RT6_TABLE_DFLT);
 	if (!mrt)
 		return -ENOENT;
-- 
2.34.1

On Fri, Jan 23, 2026 at 2:15 AM Kery Qi <qikeyu2017@gmail.com> wrote:
>
> commit 99253eb750fd ("ipv6: check sk sk_type and protocol early in
> ip_mroute_set/getsockopt") fixed the issue for ip6_mroute_setsockopt()
> and ip6_mroute_getsockopt() by checking socket type and protocol
> before accessing raw6_sk(sk)->ip6mr_table.
>
> However, ip6mr_ioctl() and ip6mr_compat_ioctl() were missed in that fix
> and have the same problem: they access raw6_sk(sk)->ip6mr_table without
> first verifying that the socket is a raw socket with IPPROTO_ICMPV6
> protocol.
>
> This allows a permission bypass where a user with CAP_NET_RAW can create
> a non-ICMPv6 raw socket (e.g., IPPROTO_UDP, IPPROTO_TCP, or any other
> protocol) and use SIOCGETMIFCNT_IN6 or SIOCGETSGCNT_IN6 ioctls to query
> IPv6 multicast routing statistics. This bypasses the access control that
> restricts mroute operations to ICMPv6 sockets only.
>
> For example, the following would succeed on a vulnerable kernel:
>
>     int fd = socket(AF_INET6, SOCK_RAW, IPPROTO_UDP);
>     struct sioc_mif_req6 req = { .mifi = 0 };
>     ioctl(fd, SIOCGETMIFCNT_IN6, &req);  // should fail with EOPNOTSUPP
>
> While the direct security impact is limited to information disclosure of
> multicast routing statistics, this violates the intended access control
> model where only ICMPv6 raw sockets should be able to access mroute
> functionalities.
>

Where has this been documented? An RFC perhaps ?

This change could break applications if they were unaware of such rules.

I fail to see how querying statistics could be a risk.

What about the RTNL_FAMILY_IPMR rtnetlink interface ? I am sure it is
available to any user.