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