Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 10:49:23 +0800
From: "Qian Zhang" <>
To: oss-security <>
Cc: secalert <>, 
	zhangqian-c <>, 
	cve-assign <>
Subject: CVE-2016-8632 -- Linux kernel: tipc_msg_build() doesn't validate MTU that can trigger heap overflow

Hi all,
Recently I found a flaw in the TIPC networking subsystem which could allow for memory corruption and possible privilege escalation (CVE-2016-8632).
I made this post to oss-sec for outlining the flaw and letting people know the CVE.
First upstream patch(it hasn't been pushed upstream yet):

Forgot to add CVE Assignment Team to CC list in the last mail.

Recently i took a glance for function tipc_msg_build() at net/tipc/msg.c:244 on linux kernel 4.8.1.
It seems like tipc_msg_build() doesn't validate the parameter pktmax(MTU) passed from tipc_sendmcast(), and if I could change this value lower than (INT_H_SIZE + mhsz), It maybe can trigger heap overflow in skb->data.
static int tipc_sendmcast(struct  socket *sock, struct tipc_name_seq *seq,
                  struct msghdr *msg, size_t dsz, long timeo) 
         . . .
         mtu = tipc_bcast_get_mtu(net);
         rc = tipc_msg_build(mhdr, msg, 0, dsz, mtu, &pktchain);
         . . .
int tipc_msg_build(struct tipc_msg *mhdr, struct msghdr *m,
                      int offset, int dsz, int pktmax, struct sk_buff_head *list)
         int mhsz = msg_hdr_sz(mhdr);
         int msz = mhsz + dsz;
         int pktno = 1;
         int pktsz;
         int pktrem = pktmax;
         int drem = dsz;
         struct tipc_msg pkthdr;
         struct sk_buff *skb;
         char *pktpos;
         int rc;
         msg_set_size(mhdr, msz);
         . . .
         /* Prepare first fragment */
         skb = tipc_buf_acquire(pktmax);
         if (!skb)
                   return -ENOMEM;
         __skb_queue_tail(list, skb);
         pktpos = skb->data;
         skb_copy_to_linear_data(skb, &pkthdr, INT_H_SIZE);
         pktpos += INT_H_SIZE;
         pktrem -= INT_H_SIZE;
         skb_copy_to_linear_data_offset(skb, INT_H_SIZE, mhdr, mhsz);
         pktpos += mhsz;
         pktrem -= mhsz;
         . . .
The MTU value can obtained from tipc_bcast_get_mtu(), and this value can be settled by tipc_link_set_mtu(), I search around withing the source code of 4.8.1, founded that only tipc_bcbase_select_primary() invokes tipc_link_set_mtu().
static void tipc_bcbase_select_primary(struct net *net)
         . . .
         for (i = 0; i < MAX_BEARERS; i++) {
                   if (!bb->dests[i])
                   mtu = tipc_bearer_mtu(net, i);
                   if (mtu < tipc_link_mtu(bb->link))
                            tipc_link_set_mtu(bb->link, mtu);
                   . . .
int tipc_bearer_mtu(struct net *net, u32 bearer_id)
         int mtu = 0;
         struct tipc_bearer *b;
         b = rcu_dereference_rtnl(tipc_net(net)->bearer_list[bearer_id]);
         if (b)
                   mtu = b->mtu;
         return mtu;
Obviously tipc_bearer_mtu() return MTU value by object tipc_bearer which directly inherited from net device MTU.(eth0 MTU on my situation)
Red Hat Product Security has assigned CVE-2016-8632 to this vulnerability.
This issue may cause memory corruption and even escalate privilege if we layout the appropriate heap space by any user with CAP_NET_ADMIN.
I use kernel 4.6.2 x86_64 to reproduce the issue, but it also seems like vulnerable in the latest kernel version(4.9-rc4).

First upstream patch:
This vulnerability was found by Qian Zhang from MarvelTeam Qihoo 360.
On Mon, Nov 7, 2016 at 9:29 AM, Red Hat Product Security <> wrote:
>I've asked our team to assign you one from the internal pool. Please, use CVE-2016-8632.
>The next step is usually making a post explaining this issue to OSS-sec list. Ben (upstream) mentions that this patch is already public ( ) I was planning to unembargo this flaw.
>The next step as we discussed would be for you to make a post to oss-sec outlining the flaw and letting people know the CVE. Please make the post to oss-sec explaining the flaw and referencing the first upstream patch.
>Thanks, let me know if I can help.
>Wade Mealing

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.