All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 214711] New: Memory leakage from kernel to user space
@ 2021-10-13 20:58 bugzilla-daemon
  2021-10-13 20:59 ` [Bug 214711] Memory leakage from kernel to user space in scsi_ioctl.c bugzilla-daemon
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-13 20:58 UTC (permalink / raw)
  To: linux-scsi

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

            Bug ID: 214711
           Summary: Memory leakage from kernel to user space
           Product: SCSI Drivers
           Version: 2.5
    Kernel Version: 5.15-rc5
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: scsi_drivers-other@kernel-bugs.osdl.org
          Reporter: bao00065@umn.edu
        Regression: No

Hi Maintainer,
I just found an uninitialized value use bug that causes memory leakage from
kernel to user space. Here are the details:

Vulnerable function is in /drivers/scsi/scsi_ioctl.c



static int scsi_put_cdrom_generic_arg(const struct cdrom_generic_command *cgc,
                                      void __user *arg)
{
#ifdef CONFIG_COMPAT
        if (in_compat_syscall()) {
                struct compat_cdrom_generic_command cgc32 = {
                        .buffer         = (uintptr_t)(cgc->buffer),
                        .buflen         = cgc->buflen,
                        .stat           = cgc->stat,
                        .sense          = (uintptr_t)(cgc->sense),
                        .data_direction = cgc->data_direction,
                        .quiet          = cgc->quiet,
                        .timeout        = cgc->timeout,
                        .unused         = (uintptr_t)(cgc->unused),
                };
                memcpy(&cgc32.cmd, &cgc->cmd, CDROM_PACKET_SIZE);

                if (copy_to_user(arg, &cgc32, sizeof(cgc32))) 
                        return -EFAULT;

                return 0;
        }
#endif
        if (copy_to_user(arg, cgc, sizeof(*cgc)))
                return -EFAULT;

        return 0;
}

The issue is, struct cgc32 is partially initialized since pad[3] are not
initialized. Then this struct is passed to copy_to_user, and 3 bytes are leaked
from kernel space to userspace. 


The struct is declared here:
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;
};
#endif

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

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

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

* [Bug 214711] Memory leakage from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
@ 2021-10-13 20:59 ` bugzilla-daemon
  2021-10-14  4:06 ` bugzilla-daemon
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-13 20:59 UTC (permalink / raw)
  To: linux-scsi

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

Andrew Bao (bao00065@umn.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Memory leakage from kernel  |Memory leakage from kernel
                   |to user space               |to user space in
                   |                            |scsi_ioctl.c

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

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

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

* [Bug 214711] Memory leakage from kernel to user space in scsi_ioctl.c
  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
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14  4:06 UTC (permalink / raw)
  To: linux-scsi

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

Bart Van Assche (bvanassche@acm.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bvanassche@acm.org

--- Comment #1 from Bart Van Assche (bvanassche@acm.org) ---
Isn't this called an information leak instead of a memory leak?

Additionally, 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 draft: "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."

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

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

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

* [Bug 214711] Information leakage from kernel to user space in scsi_ioctl.c
  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 ` bugzilla-daemon
  2021-10-14 15:06 ` [Bug 214711] Information leak " bugzilla-daemon
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14 15:05 UTC (permalink / raw)
  To: linux-scsi

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

Andrew Bao (bao00065@umn.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Memory leakage from kernel  |Information leakage from
                   |to user space in            |kernel to user space in
                   |scsi_ioctl.c                |scsi_ioctl.c

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

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

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

* [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
                   ` (2 preceding siblings ...)
  2021-10-14 15:05 ` [Bug 214711] Information " bugzilla-daemon
@ 2021-10-14 15:06 ` bugzilla-daemon
  2021-10-14 15:15 ` bugzilla-daemon
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14 15:06 UTC (permalink / raw)
  To: linux-scsi

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

Andrew Bao (bao00065@umn.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Information leakage from    |Information leak from
                   |kernel to user space in     |kernel to user space in
                   |scsi_ioctl.c                |scsi_ioctl.c

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

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

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

* [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
                   ` (3 preceding siblings ...)
  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
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14 15:15 UTC (permalink / raw)
  To: linux-scsi

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

--- Comment #2 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.

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

* [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
                   ` (4 preceding siblings ...)
  2021-10-14 15:15 ` bugzilla-daemon
@ 2021-10-14 15:16 ` bugzilla-daemon
  2021-10-14 18:21 ` bugzilla-daemon
  2021-10-16 21:30 ` bugzilla-daemon
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14 15:16 UTC (permalink / raw)
  To: linux-scsi

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.

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

* [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
                   ` (5 preceding siblings ...)
  2021-10-14 15:16 ` bugzilla-daemon
@ 2021-10-14 18:21 ` bugzilla-daemon
  2021-10-16 21:30 ` bugzilla-daemon
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-14 18:21 UTC (permalink / raw)
  To: linux-scsi

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

--- Comment #4 from Bart Van Assche (bvanassche@acm.org) ---
C and C++ compilers always initialize all named data members of a data
structure in case of aggregate initialization. See also
https://stackoverflow.com/questions/10828294/c-and-c-partial-initialization-of-automatic-structure.
However, whether or not unnamed padding bytes and bits are initialized depends
on the language standard supported by the compiler. See e.g.
https://gustedt.wordpress.com/2012/10/24/c11-defects-initialization-of-padding/

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

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

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

* [Bug 214711] Information leak from kernel to user space in scsi_ioctl.c
  2021-10-13 20:58 [Bug 214711] New: Memory leakage from kernel to user space bugzilla-daemon
                   ` (6 preceding siblings ...)
  2021-10-14 18:21 ` bugzilla-daemon
@ 2021-10-16 21:30 ` bugzilla-daemon
  7 siblings, 0 replies; 9+ messages in thread
From: bugzilla-daemon @ 2021-10-16 21:30 UTC (permalink / raw)
  To: linux-scsi

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

--- Comment #5 from Andrew Bao (bao00065@umn.edu) ---
Thank you

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

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

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

end of thread, other threads:[~2021-10-16 21:30 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-10-14 18:21 ` bugzilla-daemon
2021-10-16 21:30 ` bugzilla-daemon

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.