linux-kernel - [PATCH 4.10 43/48] drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170316142922.920939265@linuxfoundation.org>
Date:   Thu, 16 Mar 2017 23:30:27 +0900
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Richard Biener <rguenther@...e.com>,
        Takashi Iwai <tiwai@...e.de>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>
Subject: [PATCH 4.10 43/48] drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var

4.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <tiwai@...e.de>

commit d8e9b2b9097c117880dc22933239d05199c60b96 upstream.

send_display_send_uevent() sends two environment variable, and the
first one GVT_DISPLAY_READY is set including a new line at the end of
the string; that is obviously superfluous and wrong -- at least, it
*looks* so when you only read the code.

However, it doesn't appear in the actual output by a (supposedly
unexpected) trick.  The code uses snprintf() and truncates the string
in size 20 bytes.  This makes the string as GVT_DISPLAY_READY=0 or
...=1 including the trailing NUL-letter.  That is, the '\n' found in
the format string is always cut off as a result.

Although the code gives the correct result, it is confusing.  This
patch addresses it, just removing the superfluous '\n' from the format
string for avoiding further confusion.  If the argument "ready" were
not a  bool, the size 20 should be corrected as well.  But it's a
bool, so we can leave the magic number 20 as is for now.

FWIW, the bug was spotted by a new GCC7 warning:
  drivers/gpu/drm/i915/gvt/handlers.c: In function 'pvinfo_mmio_write':
  drivers/gpu/drm/i915/gvt/handlers.c:1042:34: error: 'snprintf' output truncated before the last format character [-Werror=format-truncation=]
    snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
                                    ^~~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/i915/gvt/handlers.c:1042:2: note: 'snprintf' output 21 bytes into a destination of size 20
    snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1025903
Reported-by: Richard Biener <rguenther@...e.com>
Signed-off-by: Takashi Iwai <tiwai@...e.de>
Signed-off-by: Zhenyu Wang <zhenyuw@...ux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 drivers/gpu/drm/i915/gvt/handlers.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1039,7 +1039,7 @@ static int send_display_ready_uevent(str
 	char vmid_str[20];
 	char display_ready_str[20];

-	snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
+	snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d", ready);
 	env[0] = display_ready_str;

 	snprintf(vmid_str, 20, "VMID=%d", vgpu->id);