linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
Date: Thu, 14 Oct 2021 15:16:28 +0000	[thread overview]
Message-ID: <bug-214711-11613-sU6xQ4PITD@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-214711-11613@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=214711

--- Comment #3 from Andrew Bao (bao00065@umn.edu) ---
Hi Bart,
Yes, It is an information leak.

"my understanding of the C standard is that a compiler is required to
zero-initialize members that have not been mentioned in an initializer list.
From the ANSI C 202x d"raft: "The initialization shall occur in initializer
list order, each initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject; all subobjects that are
not
initialized explicitly shall be initialized implicitly the same as objects that
have static storage duration."

I am wondering in what condition the compiler will zero-initialize the field in
a struct. And what is the initializer in the context? Let say we have a struct
foo:

struct foo{
       int  a;
       int b;
       int c;
};
method 1:

struct foo f; 
f.a = 1;
f.b = 2;

In method 1, will the compiler zero-initialize the field f.c?

method 2:
struct foo f = {
                        .a      =   1
                        .b      =   2

                };
In method 2, will the compiler zero-initialize the field f.c?


By the way,
struct compat_cdrom_generic_command {
        unsigned char   cmd[CDROM_PACKET_SIZE];
        compat_caddr_t  buffer;
        compat_uint_t   buflen;
        compat_int_t    stat;
        compat_caddr_t  sense;
        unsigned char   data_direction;
        unsigned char   pad[3];
        compat_int_t    quiet;
        compat_int_t    timeout;
        compat_caddr_t  unused;
};
If this struct does not declare unsigned char pad[3] in order to fill with
padding, will the compiler zero-initialize 3 bytes holes for this struct?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2021-10-14 15:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
2021-10-13 20:59 ` [Bug 214711] Memory leakage from kernel to user space in scsi_ioctl.c bugzilla-daemon
2021-10-14  4:06 ` bugzilla-daemon
2021-10-14 15:05 ` [Bug 214711] Information " bugzilla-daemon
2021-10-14 15:06 ` [Bug 214711] Information leak " bugzilla-daemon
2021-10-14 15:15 ` bugzilla-daemon
2021-10-14 15:16 ` bugzilla-daemon [this message]
2021-10-14 18:21 ` bugzilla-daemon
2021-10-16 21:30 ` bugzilla-daemon

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=bug-214711-11613-sU6xQ4PITD@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-scsi@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 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).