linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 'skb' buffer address information leakage
@ 2017-07-04  5:12 Dison River
  2017-07-04  5:27 ` Jakub Kicinski
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Dison River @ 2017-07-04  5:12 UTC (permalink / raw)
  To: samuel, netdev, linux-kernel, qca_merez, kvalo, linux-wireless,
	jakub.kicinski, davem, oss-drivers, security, wil6210

Hi all:
I'd found several address leaks of "skb" buffer.When i have a
arbitrary address write vulnerability in kernel(enabled kASLR),I can
use skb's address find sk_destruct's address and overwrite it. And
then,invoke close(sock_fd) function can trigger the
shellcode(sk_destruct func).

In kernel 4.12-rc7
drivers/net/irda/vlsi_ir.c:326           seq_printf(seq, "skb=%p
data=%p hw=%p\n", rd->skb, rd->buf, rd->hw);
drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
         seq_printf(file, " frag=%p", skb);
drivers/net/wireless/ath/wil6210/debugfs.c:926           seq_printf(s,
"  SKB = 0x%p\n", skb);

Thanks.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 'skb' buffer address information leakage
  2017-07-04  5:12 'skb' buffer address information leakage Dison River
@ 2017-07-04  5:27 ` Jakub Kicinski
  2017-07-04  7:44 ` Greg KH
  2017-07-04 18:13 ` Stephen Hemminger
  2 siblings, 0 replies; 4+ messages in thread
From: Jakub Kicinski @ 2017-07-04  5:27 UTC (permalink / raw)
  To: Dison River
  Cc: samuel, netdev, linux-kernel, qca_merez, kvalo, linux-wireless,
	davem, oss-drivers, security, wil6210

On Tue, 4 Jul 2017 13:12:18 +0800, Dison River wrote:
> drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
>          seq_printf(file, " frag=%p", skb);

FWIW that's actually not a skb pointer.  The structure is defined like
this:

struct nfp_net_tx_buf {
        union { 
                struct sk_buff *skb;
                void *frag;
        };
        dma_addr_t dma_addr;
        short int fidx;
        u16 pkt_cnt;
        u32 real_len;
};

So the line in question is actually reading the frag pointer, I just
reused the skb variable, because this has to be read via READ_ONCE()
and NULL-checked so I thought that doing it separately for skb and
frag is a waste of LOC especially in debug code.  I will queue up a
clean up for after the merge window.

Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 'skb' buffer address information leakage
  2017-07-04  5:12 'skb' buffer address information leakage Dison River
  2017-07-04  5:27 ` Jakub Kicinski
@ 2017-07-04  7:44 ` Greg KH
  2017-07-04 18:13 ` Stephen Hemminger
  2 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2017-07-04  7:44 UTC (permalink / raw)
  To: Dison River
  Cc: samuel, netdev, linux-kernel, qca_merez, kvalo, linux-wireless,
	jakub.kicinski, davem, oss-drivers, security, wil6210

On Tue, Jul 04, 2017 at 01:12:18PM +0800, Dison River wrote:
> Hi all:
> I'd found several address leaks of "skb" buffer.When i have a
> arbitrary address write vulnerability in kernel(enabled kASLR),I can
> use skb's address find sk_destruct's address and overwrite it. And
> then,invoke close(sock_fd) function can trigger the
> shellcode(sk_destruct func).
> 
> In kernel 4.12-rc7
> drivers/net/irda/vlsi_ir.c:326           seq_printf(seq, "skb=%p
> data=%p hw=%p\n", rd->skb, rd->buf, rd->hw);

Irda doesn't even work, and will crash, so it's a bit hard to see this
as a "leakage" :)

I'm going to be ripping irda out soon anyway, so this isn't a real
issue.

> drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
>          seq_printf(file, " frag=%p", skb);
> drivers/net/wireless/ath/wil6210/debugfs.c:926           seq_printf(s,
> "  SKB = 0x%p\n", skb);


debugfs is by nature, root-only access, so the potential for issues here
is lower than "any user can get this info".  That being said, patches
for these are always appreciated.

I also need to respin my "turn %p pointers off" patchset to prevent
future stuff like this from happening.  I want to get to that after
4.13-rc1 is out.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 'skb' buffer address information leakage
  2017-07-04  5:12 'skb' buffer address information leakage Dison River
  2017-07-04  5:27 ` Jakub Kicinski
  2017-07-04  7:44 ` Greg KH
@ 2017-07-04 18:13 ` Stephen Hemminger
  2 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2017-07-04 18:13 UTC (permalink / raw)
  To: Dison River
  Cc: samuel, netdev, linux-kernel, qca_merez, kvalo, linux-wireless,
	jakub.kicinski, davem, oss-drivers, security, wil6210

On Tue, 4 Jul 2017 13:12:18 +0800
Dison River <pwn2river@gmail.com> wrote:

> Hi all:
> I'd found several address leaks of "skb" buffer.When i have a
> arbitrary address write vulnerability in kernel(enabled kASLR),I can
> use skb's address find sk_destruct's address and overwrite it. And
> then,invoke close(sock_fd) function can trigger the
> shellcode(sk_destruct func).
> 
> In kernel 4.12-rc7
> drivers/net/irda/vlsi_ir.c:326           seq_printf(seq, "skb=%p
> data=%p hw=%p\n", rd->skb, rd->buf, rd->hw);
> drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
>          seq_printf(file, " frag=%p", skb);
> drivers/net/wireless/ath/wil6210/debugfs.c:926           seq_printf(s,
> "  SKB = 0x%p\n", skb);
> 
> Thanks.

Debugfs support is optional with Netronome. If concerned about security,
then it should be disabled.

The WIIL6210 driver debugfs has other worse address leaks.
The whole debugfs support in this driver should be made optional
(or removed).

The VLSI /oroc interface likewise should just be removed (or made
optional). Most distributions do not build IRDA anymore anyway.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-07-04 18:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-04  5:12 'skb' buffer address information leakage Dison River
2017-07-04  5:27 ` Jakub Kicinski
2017-07-04  7:44 ` Greg KH
2017-07-04 18:13 ` Stephen Hemminger

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).