All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Meelis Roos <mroos@linux.ee>
Cc: sparclinux@vger.kernel.org, edumazet@google.com, netdev@vger.kernel.org
Subject: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
Date: Tue, 23 Feb 2016 12:12:44 +0000	[thread overview]
Message-ID: <20160223121244.GI28756@oracle.com> (raw)
In-Reply-To: <20160222010201.GB23053@oracle.com>


I figured out what's the root-cause of my panics.

In my case, for the stack shown in 
 http://marc.info/?l=linux-sparc&m\x145610295109214&w=2
(which also has all the details about the issue),

tcp_make_synack has been called with attach_req set to true
so it sets up the skb->sk via:

        if (attach_req) {
                skb_set_owner_w(skb, req_to_sk(req));
        } else { /* .. */

Now, req is a struct inet_request_sock, and we are casting this
as a struct sock, to later get the ->sk_policy[1] in the xfrm
code. Consider the sizes of these structures between 32 and 64 bits:

  sizeof             32-bit        64-bit
-------------------------------------------
request_sock          256           312
inet_request_sock     272           328
sock                  688          1216

And offsetof sk_policy[1] is 256 on the 32-bit v440, whereas
it is 520 on my 64-bit T5. 

Thus on the v440, the sk_policy[1] is pointing at somewhere
in the middle of stuff set up by tcp_openreq_init() (the ireq
flags initialization).

Even on the 64-bit arch, trying to do req_to_sk(req) and accessing
fields beyond the sock_common, e.g., between offset 312 and 328 
may not give you the fields you are looking for? 

so how is this supposed to work? (Evidently it worked for Meelis
before, but I dont know if that was before or after  commit
9e17f8a475).

--Sowmini


WARNING: multiple messages have this Message-ID (diff)
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Meelis Roos <mroos@linux.ee>
Cc: sparclinux@vger.kernel.org, edumazet@google.com, netdev@vger.kernel.org
Subject: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
Date: Tue, 23 Feb 2016 07:12:44 -0500	[thread overview]
Message-ID: <20160223121244.GI28756@oracle.com> (raw)
In-Reply-To: <20160222010201.GB23053@oracle.com>


I figured out what's the root-cause of my panics.

In my case, for the stack shown in 
 http://marc.info/?l=linux-sparc&m=145610295109214&w=2
(which also has all the details about the issue),

tcp_make_synack has been called with attach_req set to true
so it sets up the skb->sk via:

        if (attach_req) {
                skb_set_owner_w(skb, req_to_sk(req));
        } else { /* .. */

Now, req is a struct inet_request_sock, and we are casting this
as a struct sock, to later get the ->sk_policy[1] in the xfrm
code. Consider the sizes of these structures between 32 and 64 bits:

  sizeof             32-bit        64-bit
-------------------------------------------
request_sock          256           312
inet_request_sock     272           328
sock                  688          1216

And offsetof sk_policy[1] is 256 on the 32-bit v440, whereas
it is 520 on my 64-bit T5. 

Thus on the v440, the sk_policy[1] is pointing at somewhere
in the middle of stuff set up by tcp_openreq_init() (the ireq
flags initialization).

Even on the 64-bit arch, trying to do req_to_sk(req) and accessing
fields beyond the sock_common, e.g., between offset 312 and 328 
may not give you the fields you are looking for? 

so how is this supposed to work? (Evidently it worked for Meelis
before, but I dont know if that was before or after  commit
9e17f8a475).

--Sowmini

  reply	other threads:[~2016-02-23 12:12 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 15:21 Recent spontaneous reboots on multiple machines Meelis Roos
2016-01-06 15:22 ` Meelis Roos
2016-01-07 17:41 ` Sowmini Varadhan
2016-01-07 19:46 ` Meelis Roos
2016-01-07 20:14 ` Sowmini Varadhan
2016-01-08 17:20 ` Sowmini Varadhan
2016-01-08 19:02 ` David Miller
2016-01-08 20:18 ` mroos
2016-01-08 21:15 ` Sowmini Varadhan
2016-01-08 21:29 ` Meelis Roos
2016-01-10 10:03 ` Meelis Roos
2016-02-05  9:06 ` Meelis Roos
2016-02-14 10:51 ` Sowmini Varadhan
2016-02-15  5:54 ` Meelis Roos
2016-02-18  2:30 ` Sowmini Varadhan
2016-02-22  1:02 ` Sowmini Varadhan
2016-02-23 12:12   ` Sowmini Varadhan [this message]
2016-02-23 12:12     ` Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines) Sowmini Varadhan
2016-02-23 19:36     ` Meelis Roos
2016-02-23 19:36       ` Meelis Roos
2016-02-23 19:39       ` Sowmini Varadhan
2016-02-23 19:39         ` Sowmini Varadhan
2016-02-23 20:45         ` Meelis Roos
2016-02-23 20:45           ` Meelis Roos
2016-02-23 20:20       ` Invalid sk_policy[] access David Miller
2016-02-23 20:20         ` David Miller
2016-02-23 20:29         ` Sowmini Varadhan
2016-02-23 20:29           ` Sowmini Varadhan
2016-02-23 20:37           ` mroos
2016-02-23 20:37             ` mroos
2016-02-23 20:51           ` mroos
2016-02-23 20:51             ` mroos
2016-02-23 20:53             ` Sowmini Varadhan
2016-02-23 20:53               ` Sowmini Varadhan
2016-02-23 23:05               ` David Miller
2016-02-23 23:05                 ` David Miller
2016-02-23 22:59             ` David Miller
2016-02-23 22:59               ` David Miller
2016-02-23 23:59               ` Sowmini Varadhan
2016-02-23 23:59                 ` Sowmini Varadhan
2016-02-24  0:23                 ` David Miller
2016-02-24  0:23                   ` David Miller

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=20160223121244.GI28756@oracle.com \
    --to=sowmini.varadhan@oracle.com \
    --cc=edumazet@google.com \
    --cc=mroos@linux.ee \
    --cc=netdev@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.