Nouveau - Nov 2019 - [Bug 112201] New: Syscall param ioctl(generic) points to uninitialised byte(s)

https://bugs.freedesktop.org/show_bug.cgi?id=112201

            Bug ID: 112201
           Summary: Syscall param ioctl(generic) points to uninitialised
                    byte(s)
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: not set
          Priority: not set
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: stratus at tuta.io
        QA Contact: xorg-team at lists.x.org

Dear bugzilla,
I built the example program here:
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glXIntro.xml
$ gcc -Wall -Wextra -o glxample glxample.c -lX11 -lGL
(The test app works and shows a little yellow window then exits after 10
seconds as it is supposed to)
I ran it under valgrind, with the relevant packages built unstripped.
I found the same error, but from a different initial function, with xfwm4,
while trying to resolve an issue with that in another as yet unresolved bug
report, which includes that valgrind trace, and more os/hw details:
https://bugzilla.xfce.org/show_bug.cgi?id=16032
I was intending to find a simple test app to try out the function
glXQueryServerString to confirm if this problem was in mesa / libdrm but
didn't
even need to do that.
Any ideas what is happening here, and if this apparent buffer overflow could be
relevant to the xfwm4 bug, or something extra besides that?

$ valgrind --tool=memcheck --fullpath-after=/home/name/debug-xwfm4
--num-callers=100 ./glxample 
==3018== Memcheck, a memory error detector
==3018== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3018== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3018== Command: ./glxample
==3018== 
==3018== Syscall param ioctl(generic) points to uninitialised byte(s)
==3018==    at 0x4B3325B: ioctl (in /usr/lib/libc-2.30.so)
==3018==    by 0x52280DE: drmIoctl
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/xf86drm.c:180)
==3018==    by 0x52290F3: drmCommandWriteRead
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/xf86drm.c:2644)
==3018==    by 0xC0679DA: nouveau_object_ioctl
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:88)
==3018==    by 0xC068286: nouveau_object_init
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:262)
==3018==    by 0xC06A55C: nouveau_device_new
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:389)
==3018==    by 0x5D5D0AD: nouveau_drm_screen_create
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:101)
==3018==    by 0x5AD319A: pipe_nouveau_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/target-helpers/drm_helper.h:76)
==3018==    by 0x5B7186C: pipe_loader_drm_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c:314)
==3018==    by 0x5B7134E: pipe_loader_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader.c:128)
==3018==    by 0x5AD6EA1: dri2_init_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/state_trackers/dri/dri2.c:2036)
==3018==    by 0x5AD4725: driCreateNewScreen2
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/mesa/drivers/dri/common/dri_util.c:154)
==3018==    by 0x51B7570: dri2CreateScreen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/dri2_glx.c:1288)
==3018==    by 0x51A80F0: AllocAndFetchScreenConfigs
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:817)
==3018==    by 0x51A84C3: __glXInitialize
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:940)
==3018==    by 0x51A49D7: glXGetFBConfigs
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1660)
==3018==    by 0x51A5099: glXChooseFBConfig
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1599)
==3018==    by 0x4C386F9: glXChooseFBConfig (in /usr/lib/libGLX.so.0.0.0)
==3018==    by 0x109301: main (in /home/name/debug-xwfm4/glxample)
==3018==  Address 0x4f1a382 is 2 bytes inside a block of size 72 alloc'd
==3018==    at 0x483877F: malloc
(/build/valgrind/src/valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:309)
==3018==    by 0xC068237: nouveau_object_init
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:251)
==3018==    by 0xC06A55C: nouveau_device_new
(/symbolpkgs/libdrm/src/build/../libdrm-2.4.100/nouveau/nouveau.c:389)
==3018==    by 0x5D5D0AD: nouveau_drm_screen_create
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:101)
==3018==    by 0x5AD319A: pipe_nouveau_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/target-helpers/drm_helper.h:76)
==3018==    by 0x5B7186C: pipe_loader_drm_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c:314)
==3018==    by 0x5B7134E: pipe_loader_create_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/auxiliary/pipe-loader/pipe_loader.c:128)
==3018==    by 0x5AD6EA1: dri2_init_screen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/gallium/state_trackers/dri/dri2.c:2036)
==3018==    by 0x5AD4725: driCreateNewScreen2
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/mesa/drivers/dri/common/dri_util.c:154)
==3018==    by 0x51B7570: dri2CreateScreen
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/dri2_glx.c:1288)
==3018==    by 0x51A80F0: AllocAndFetchScreenConfigs
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:817)
==3018==    by 0x51A84C3: __glXInitialize
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxext.c:940)
==3018==    by 0x51A49D7: glXGetFBConfigs
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1660)
==3018==    by 0x51A5099: glXChooseFBConfig
(/symbolpkgs/mesa/src/build/../mesa-19.2.2/src/glx/glxcmds.c:1599)
==3018==    by 0x4C386F9: glXChooseFBConfig (in /usr/lib/libGLX.so.0.0.0)
==3018==    by 0x109301: main (in /home/name/debug-xwfm4/glxample)
==3018== 
==3018== 
==3018== HEAP SUMMARY:
==3018==     in use at exit: 964,131 bytes in 3,934 blocks
==3018==   total heap usage: 8,989 allocs, 5,055 frees, 3,301,060 bytes
allocated
==3018== 
==3018== LEAK SUMMARY:
==3018==    definitely lost: 64 bytes in 2 blocks
==3018==    indirectly lost: 0 bytes in 0 blocks
==3018==      possibly lost: 80,104 bytes in 537 blocks
==3018==    still reachable: 883,963 bytes in 3,395 blocks
==3018==         suppressed: 0 bytes in 0 blocks
==3018== Rerun with --leak-check=full to see details of leaked memory
==3018== 
==3018== Use --track-origins=yes to see where uninitialised values come from
==3018== For lists of detected and suppressed errors, rerun with: -s
==3018== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 0 from 0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191103/8e3174d5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=112201

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
This is expected. valgrind does not understand how the ioctl works, so it
thinks that uninitialized memory is being read. But that's not an actual
issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191103/b10d6898/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=112201

--- Comment #2 from stratus at tuta.io ---
So this is not causing any problems, I suppose it's controlling the hardware
by
reading/writing to memory addresses provided by the kernel, and valgrind is
giving a false positive, thank you for your rapid answer explaining things. I
can look at some other things instead then.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191103/2440a579/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=112201

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to stratus from comment #2)
> So this is not causing any problems, I suppose it's controlling the
hardware
> by reading/writing to memory addresses provided by the kernel, and valgrind
> is giving a false positive, thank you for your rapid answer explaining
> things. I can look at some other things instead then.
Nope, the issue has nothing to do with that. It has to do with valgrind not
understanding how that ioctl() works. That specific one works by the kernel
filling in some data structures, but valgrind thinks that the ioctl is being
passed data. But that's not the case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191103/4b1b9f78/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=112201

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #4 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/515.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/d981af28/attachment.html>