From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <john.cs.hey@gmail.com>
Cc: <davem@davemloft.net>, <dsahern@kernel.org>,
<edumazet@google.com>, <horms@kernel.org>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>
Subject: Re: [Bug] "general protection fault in calipso_sock_setattr" in Linux kernel v6.12
Date: Wed, 21 May 2025 11:08:09 -0700 [thread overview]
Message-ID: <20250521181024.44883-1-kuniyu@amazon.com> (raw)
In-Reply-To: <CAP=Rh=M1LzunrcQB1fSGauMrJrhL6GGps5cPAKzHJXj6GQV+-g@mail.gmail.com>
From: John <john.cs.hey@gmail.com>
Date: Wed, 21 May 2025 22:50:38 +0800
> Dear Linux Kernel Maintainers,
>
> I hope this message finds you well.
>
> I am writing to report a potential vulnerability I encountered during
> testing of the Linux Kernel version v6.12.
>
> Git Commit: adc218676eef25575469234709c2d87185ca223a (tag: v6.12)
>
> Bug Location: calipso_sock_setattr+0xf6/0x380 net/ipv6/calipso.c:1128
>
> Bug report: https://hastebin.com/share/iredodibar.yaml
>
> Complete log: https://hastebin.com/share/biqowozonu.perl
>
> Entire kernel config: https://hastebin.com/share/huqucavidu.ini
Thanks for the report.
>
> Root Cause Analysis:
> The crash is caused by a NULL pointer dereference in txopt_get() (at
> include/net/ipv6.h:390) due to an uninitialized struct inet6_opt *opt
> field.
This is not correct. The splat says the null deref happens at
np->opt.
> RIP: 0010:txopt_get root/zhangqiang/kernel_fuzzing/Drivers_Fuzz/linux-6.12/include/net/ipv6.h:390 [inline]
385 static inline struct ipv6_txoptions *txopt_get(const struct ipv6_pinfo *np)
386 {
387 struct ipv6_txoptions *opt;
388
389 rcu_read_lock();
390 opt = rcu_dereference(np->opt);
and the offset is 0x70, which is of opt in struct ipv6_pinfo.
> KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
$ python3
>>> 0x70
112
$ pahole -C ipv6_pinfo vmlinux
struct ipv6_pinfo {
...
struct ipv6_txoptions * opt; /* 112 8 */
np + 0x70 = 0x70, meaning np was NULL here.
np is always initialised for IPv6 socket in inet6_create(), so this
should never happens for IPv6 sockets.
But looking at netlbl_conn_setattr(), it swtiched branch based on
sockaddr.sa_family provided by userspace, and it does not check if
the socket is actually IPv6 one.
So, the fix will be:
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index cd9160bbc919..067f707f194d 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -1165,6 +1165,9 @@ int netlbl_conn_setattr(struct sock *sk,
break;
#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6:
+ if (sk->sk_family != AF_INET6)
+ return -EPROTONOSUPPORT;
+
addr6 = (struct sockaddr_in6 *)addr;
entry = netlbl_domhsh_getentry_af6(secattr->domain,
&addr6->sin6_addr);
> The function is indirectly invoked during an SELinux policy
> enforcement path via calipso_sock_setattr(), which expects an
> initialized inet6_sk(sk)->opt structure.
> However, the socket in question does not have IPv6 tx options set up
> at the time of the call, likely due to missing or out-of-order
> initialization during socket creation or connection setup.
> This leads to an invalid access at offset +0x70, detected by KASAN,
> and results in a general protection fault.
>
> At present, I have not yet obtained a minimal reproducer for this
> issue. However, I am actively working on reproducing it, and I will
> promptly share any additional findings or a working reproducer as soon
> as it becomes available.
Try setting CALIPSO and calling connect(IPv6 addr) for IPv4 socket.
>
> Thank you very much for your time and attention to this matter. I
> truly appreciate the efforts of the Linux kernel community.
Could you provide your full name so that I can give proper credit
in Reported-by tag ?
next prev parent reply other threads:[~2025-05-21 18:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 14:50 [Bug] "general protection fault in calipso_sock_setattr" in Linux kernel v6.12 John
2025-05-21 18:08 ` Kuniyuki Iwashima [this message]
2025-05-22 15:25 ` John
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250521181024.44883-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.cs.hey@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).