netdev - Re: [ROSE] rose dereferenced pointer kernel panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+b05+AgnLxBvG6QBmHJu=vQhLc9fs9Sonp-Q+4-Kxi3UQ@mail.gmail.com>
Date:   Wed, 2 Jan 2019 12:52:09 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Bernard Pidoux <f6bvp@...e.fr>
Cc:     David Ranch <linux-hams@...nnet.net>, ralf@...ux-mips.org,
        David Miller <davem@...emloft.net>, linux-hams@...r.kernel.org,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: [ROSE] rose dereferenced pointer kernel panic

On Wed, Jan 2, 2019 at 12:12 AM Bernard Pidoux <f6bvp@...e.fr> wrote:
>
> Hi David,
>
> In my previous message I should have reported the following patch rather than the one I reported.
>
> The reason is that the bug is better explained here :
>
> https://marc.info/?l=linux-hams&m=154478673812818&w=2
>
> and  I hope the new proposed patch is more convenient.
>
>
> Bernard
>
>
> Le 01/01/2019 à 23:39, Bernard Pidoux a écrit :
>
> Hi David,
>
> As you already know I am still looking for the simplest way to configure a kernel rose failure situation when rose_route_frame is called with a NULL pointer.
>
> Could you explain with full details how to have "TCP/IP over AX.25 fully configured" ?
>
> More specifically how can we configure rose device without NOARP ? This is not the case when performing Dmitry Vyukov :
>
> # ip link set dev rose0 address 11:22:33:44:55
> # ip link set dev rose0 up
>
> 73 de Bernard, f6bvp
>
>
> Le 08/12/2018 à 17:23, David Ranch a écrit :
>
> Hello Bernard, Everyone,
>
> Yes, I've seen a similar behavior with another program I have here that broadcasts on all live TCP/IP interfaces when it loads.  That all depends if you have TCP/IP over AX.25 fully configured on your machine.  If you do, this cp,,amd should key up your radio to send out an ARP:
>
>     ping -b -c 1 <broadcast IP on your ROSE or AX.25 interface>
>    --
>    d710: fm KI6ZHD to QST ctl UI pid=CC(IP) len 84
>    IP: len 84 44.4.10.39->44.4.10.127 ihl 20 ttl 64 DF prot ICMP
>    ICMP: type Echo Request id 50814 seq 1
>    P�.\
>    �~.
>    ................ !"#$%&'()*+,-./01234567
>    --
>
> Btw, I've been aware of this ROSE panic issue for some time and I'm pretty sure I forwarded those details on to you but that was many years ago.  Another way to reproduce a ROSE panic is, if I remember correctly, you remove the backing AX.25 interface's connection (say killing kisssattach for ax0) on a ROSE interface that has an IP, that will also panic the kernel every time.
>
> --David
> KI6ZHD

+mailing lists

Hi Bernard,

I've provided a bit more information on what I did here:
https://groups.google.com/d/msg/syzkaller/v-4B3zoBC-4/MVgYoeSQCgAJ

I really did not do anything fancy.

FWIW I had to do the following locally just to prevent rose from
crashing my machine all the time. I don't know if it's the right fix
or not, I just used this as stop-gap.

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 77e9f85a2c92..218308a3c02c 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -874,6 +874,8 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
             skb->data[ROSE_CALL_REQ_ADDR_LEN_OFF] !=
             ROSE_CALL_REQ_ADDR_LEN_VAL))
                return res;
+       if (ax25 == NULL)
+               return res;
        src_addr  = (rose_address *)(skb->data + ROSE_CALL_REQ_SRC_ADDR_OFF);
        dest_addr = (rose_address *)(skb->data + ROSE_CALL_REQ_DEST_ADDR_OFF);


rose_xmit calls rose_route_frame with ax25==NULL, then
rose_route_frame uses ax25 without any checks.