Bug 112201 - Syscall param ioctl(generic) points to uninitialised byte(s)
Summary: Syscall param ioctl(generic) points to uninitialised byte(s)
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: not set not set
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-03 02:44 UTC by stratus
Modified: 2019-11-03 03:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stratus 2019-11-03 02:44:05 UTC
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)
Comment 1 Ilia Mirkin 2019-11-03 02:57:17 UTC
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.
Comment 2 stratus 2019-11-03 03:24:55 UTC
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.
Comment 3 Ilia Mirkin 2019-11-03 03:39:55 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.