* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l @ 2021-09-23 17:04 Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-09-23 21:46 ` Alan Third 0 siblings, 1 reply; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-09-23 17:04 UTC (permalink / raw) To: 50767; +Cc: Alan Third Severity: minor Compiling image.c on a 32-bit armv7l host gives the following warnings: --8<---------------cut here---------------start------------->8--- image.c: In function ‘svg_load_image’: image.c:9999:64: warning: ‘%4d’ directive output may be truncated writing between 4 and 11 bytes into a region of size between 7 and 8 [-Wformat-truncation=] 9999 | const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; | ^~~ image.c:10002:7: note: ‘snprintf’ output 37 or more bytes (assuming 38) into a destination of size 37 10002 | snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ image.c:10134:7: warning: ‘%f’ directive output may be truncated writing between 3 and 317 bytes into a region of size between 167 and 187 [-Wformat-truncation=] 10134 | "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" " | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ image.c:10138:22: note: format string is defined here 10138 | "viewBox=\"0 0 %f %f\">" | ^~ image.c:10134:7: note: assuming directive output of 8 bytes 10134 | "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" " | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ image.c:10134:7: note: assuming directive output of 8 bytes image.c:10134:7: note: directive argument in the range [0, 16777215] image.c:10134:7: note: assuming directive output of 1 byte image.c:10161:27: note: ‘snprintf’ output 320 or more bytes (assuming 331) into a destination of size 383 10161 | || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10162 | foreground & 0xFFFFFF, width, height, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10163 | viewbox_width, viewbox_height, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10164 | background & 0xFFFFFF, | ~~~~~~~~~~~~~~~~~~~~~~ 10165 | SSDATA (encoded_contents))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~ --8<---------------cut here---------------end--------------->8--- What's TRT to do? Call snprintf twice, the first time to calculate the required buffer size? Calculate more precisely the resulting size of each argument? Inhibit the warnings? Something else? Some questions about the current code: > const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; Why specifically '%4d' for face_font_size? > int css_len = strlen (css_spec) + strlen (img->face_font_family); > css = xmalloc (css_len); > snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); > rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL); Does css_len not need to include the terminating null byte? What if xmalloc or snprintf fail? > css = xmalloc (SBYTES (lcss) + 1); > strncpy (css, SSDATA (lcss), SBYTES (lcss)); > *(css + SBYTES (lcss) + 1) = 0; Can this be replaced with xlispstrdup? Thanks, -- Basil In GNU Emacs 28.0.50 (build 1, armv7l-unknown-linux-gnueabihf, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2021-09-23 built on raspberrypi Repository revision: 90547d370f7c75b95b1d1e64b84e624e752ea6e3 Repository branch: master System Description: Raspbian GNU/Linux 11 (bullseye) Configured using: 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache --prefix=/home/pi/.local --enable-checking=structs --with-x-toolkit=lucid --with-file-notification=yes --with-x' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XPM LUCID ZLIB Important settings: value of $LC_ALL: en_IE.UTF-8 value of $LANG: en_IE.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils term/tmux term/xterm xterm byte-opt gv bytecomp byte-compile cconv iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 8 54179 7628) (symbols 24 6739 1) (strings 16 18259 2216) (string-bytes 1 596762) (vectors 8 10587) (vector-slots 4 130733 8726) (floats 8 24 229) (intervals 28 202 1) (buffers 576 10)) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 17:04 bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-09-23 21:46 ` Alan Third 2021-09-23 22:38 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 18+ messages in thread From: Alan Third @ 2021-09-23 21:46 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767 On Thu, Sep 23, 2021 at 06:04:12PM +0100, Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Severity: minor > > Compiling image.c on a 32-bit armv7l host gives the following warnings: > > --8<---------------cut here---------------start------------->8--- > image.c: In function ‘svg_load_image’: > image.c:9999:64: warning: ‘%4d’ directive output may be truncated writing between 4 and 11 bytes > into a region of size between 7 and 8 [-Wformat-truncation=] > 9999 | const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; > | ^~~ > image.c:10002:7: note: ‘snprintf’ output 37 or more bytes (assuming 38) into a destination of size 37 > 10002 | snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > image.c:10134:7: warning: ‘%f’ directive output may be truncated writing between 3 and 317 bytes > into a region of size between 167 and 187 [-Wformat-truncation=] > 10134 | "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" " > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > image.c:10138:22: note: format string is defined here > 10138 | "viewBox=\"0 0 %f %f\">" > | ^~ > image.c:10134:7: note: assuming directive output of 8 bytes > 10134 | "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" " > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > image.c:10134:7: note: assuming directive output of 8 bytes > image.c:10134:7: note: directive argument in the range [0, 16777215] > image.c:10134:7: note: assuming directive output of 1 byte > image.c:10161:27: note: ‘snprintf’ output 320 or more bytes (assuming 331) into a destination of size 383 > 10161 | || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 10162 | foreground & 0xFFFFFF, width, height, > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 10163 | viewbox_width, viewbox_height, > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 10164 | background & 0xFFFFFF, > | ~~~~~~~~~~~~~~~~~~~~~~ > 10165 | SSDATA (encoded_contents))) > | ~~~~~~~~~~~~~~~~~~~~~~~~~~ > --8<---------------cut here---------------end--------------->8--- > > What's TRT to do? Call snprintf twice, the first time to calculate the > required buffer size? Calculate more precisely the resulting size of > each argument? Inhibit the warnings? Something else? This is my code and I'm not sure, which is why there's a FIXME in there somewhere about it. > Some questions about the current code: > > > const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; > > Why specifically '%4d' for face_font_size? I figured it unlikely that anyone would be using a font size of 10000 pixels or larger and I wanted to set an upper limit on the string size. > > int css_len = strlen (css_spec) + strlen (img->face_font_family); > > css = xmalloc (css_len); > > snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); > > rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL); > > Does css_len not need to include the terminating null byte? It does. If you add up the length of the spec string which includes the escape codes, and the length of the font name, then if the font size does produce it's maximum sized string of 4 characters css_len is exactly one byte larger than the string length. > What if xmalloc or snprintf fail? Doesn't xmalloc causes some sort of error to occur? I'm not sure. If snprintf fails then I believe we should end up with an invalid CSS stylesheet and librsvg will ignore it. Perhaps there's a worse failure mode that I'm missing. > > css = xmalloc (SBYTES (lcss) + 1); > > strncpy (css, SSDATA (lcss), SBYTES (lcss)); > > *(css + SBYTES (lcss) + 1) = 0; > > Can this be replaced with xlispstrdup? Probably. -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 21:46 ` Alan Third @ 2021-09-23 22:38 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-09-23 22:49 ` Alan Third 0 siblings, 1 reply; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-09-23 22:38 UTC (permalink / raw) To: Alan Third; +Cc: 50767 Alan Third [2021-09-23 22:46 +0100] wrote: > On Thu, Sep 23, 2021 at 06:04:12PM +0100, Basil L. Contovounesios via Bug > reports for GNU Emacs, the Swiss army knife of text editors wrote: >> >> > const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; >> >> Why specifically '%4d' for face_font_size? > > I figured it unlikely that anyone would be using a font size of 10000 > pixels or larger and I wanted to set an upper limit on the string size. AFAIK %d does not truncate numbers with more digits than the specified width or precision... >> > int css_len = strlen (css_spec) + strlen (img->face_font_family); >> > css = xmalloc (css_len); >> > snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); >> > rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL); >> >> Does css_len not need to include the terminating null byte? > > It does. If you add up the length of the spec string which includes > the escape codes, and the length of the font name, then if the font > size does produce it's maximum sized string of 4 characters css_len is > exactly one byte larger than the string length. ...which would mean this only holds in the common case that face_font_size has fewer than 5 digits, right? >> What if xmalloc or snprintf fail? > > Doesn't xmalloc causes some sort of error to occur? I'm not sure. I think it exits only while Emacs is still initialising itself before entering the top-level command loop, and otherwise frees ballast memory and signals a Lisp error. At least the second snprintf in svg_load_image does check xmalloc's return value. -- Basil ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 22:38 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-09-23 22:49 ` Alan Third 2021-09-23 22:59 ` Alan Third ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Alan Third @ 2021-09-23 22:49 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767 On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote: > Alan Third [2021-09-23 22:46 +0100] wrote: > > > On Thu, Sep 23, 2021 at 06:04:12PM +0100, Basil L. Contovounesios via Bug > > reports for GNU Emacs, the Swiss army knife of text editors wrote: > >> > >> > const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; > >> > >> Why specifically '%4d' for face_font_size? > > > > I figured it unlikely that anyone would be using a font size of 10000 > > pixels or larger and I wanted to set an upper limit on the string size. > > AFAIK %d does not truncate numbers with more digits than the specified > width or precision... Hmm, I guess so. > >> > int css_len = strlen (css_spec) + strlen (img->face_font_family); > >> > css = xmalloc (css_len); > >> > snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); > >> > rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL); > >> > >> Does css_len not need to include the terminating null byte? > > > > It does. If you add up the length of the spec string which includes > > the escape codes, and the length of the font name, then if the font > > size does produce it's maximum sized string of 4 characters css_len is > > exactly one byte larger than the string length. > > ...which would mean this only holds in the common case that > face_font_size has fewer than 5 digits, right? Looks that way. I suppose in this particular case we could limit the font size to a maximum of 9999 or something, but surely there's a better way of calculating string sizes? > >> What if xmalloc or snprintf fail? > > > > Doesn't xmalloc causes some sort of error to occur? I'm not sure. > > I think it exits only while Emacs is still initialising itself before > entering the top-level command loop, and otherwise frees ballast memory > and signals a Lisp error. > > At least the second snprintf in svg_load_image does check xmalloc's > return value. None of the other uses of xmalloc in image.c check the return value either, as far as I can see, and I certainly didn't write them all... -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 22:49 ` Alan Third @ 2021-09-23 22:59 ` Alan Third 2021-09-24 6:41 ` Eli Zaretskii 2021-10-04 21:45 ` Alan Third 2 siblings, 0 replies; 18+ messages in thread From: Alan Third @ 2021-09-23 22:59 UTC (permalink / raw) To: Basil L. Contovounesios, 50767 On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote: > > I suppose in this particular case we could limit the font size to a > maximum of 9999 or something, but surely there's a better way of > calculating string sizes? Oh, can we just use Fformat and skip all of this stuff? -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 22:49 ` Alan Third 2021-09-23 22:59 ` Alan Third @ 2021-09-24 6:41 ` Eli Zaretskii 2021-10-14 15:42 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-04 21:45 ` Alan Third 2 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-09-24 6:41 UTC (permalink / raw) To: Alan Third; +Cc: contovob, 50767 > Date: Thu, 23 Sep 2021 23:49:37 +0100 > From: Alan Third <alan@idiocy.org> > Cc: 50767@debbugs.gnu.org > > > >> What if xmalloc or snprintf fail? > > > > > > Doesn't xmalloc causes some sort of error to occur? I'm not sure. > > > > I think it exits only while Emacs is still initialising itself before > > entering the top-level command loop, and otherwise frees ballast memory > > and signals a Lisp error. > > > > At least the second snprintf in svg_load_image does check xmalloc's > > return value. > > None of the other uses of xmalloc in image.c check the return value > either, as far as I can see, and I certainly didn't write them all... AFAIR, there's no need to check the return value of xmalloc, because it doesn't return if it cannot allocate memory. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-24 6:41 ` Eli Zaretskii @ 2021-10-14 15:42 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-14 16:00 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-14 15:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50767, Alan Third Eli Zaretskii [2021-09-24 09:41 +0300] wrote: >> Date: Thu, 23 Sep 2021 23:49:37 +0100 >> From: Alan Third <alan@idiocy.org> >> Cc: 50767@debbugs.gnu.org >> >> > >> What if xmalloc or snprintf fail? >> > > >> > > Doesn't xmalloc causes some sort of error to occur? I'm not sure. >> > >> > I think it exits only while Emacs is still initialising itself before >> > entering the top-level command loop, and otherwise frees ballast memory >> > and signals a Lisp error. >> > >> > At least the second snprintf in svg_load_image does check xmalloc's >> > return value. >> >> None of the other uses of xmalloc in image.c check the return value >> either, as far as I can see, and I certainly didn't write them all... > > AFAIR, there's no need to check the return value of xmalloc, because > it doesn't return if it cannot allocate memory. Are you thinking about xalloc? If not, could you please point me to the part of xmalloc that doesn't return (except for the !initialized branch in memory_full)? I'm afraid I couldn't spot it. -- Basil ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-14 15:42 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-14 16:00 ` Eli Zaretskii 2021-10-14 16:37 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-10-14 16:00 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767, alan > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: Alan Third <alan@idiocy.org>, 50767@debbugs.gnu.org > Date: Thu, 14 Oct 2021 16:42:24 +0100 > > > AFAIR, there's no need to check the return value of xmalloc, because > > it doesn't return if it cannot allocate memory. > > Are you thinking about xalloc? No, I'm thinking xmalloc. > If not, could you please point me to the part of xmalloc that > doesn't return (except for the !initialized branch in memory_full)? > I'm afraid I couldn't spot it. This part: if (!val && size) memory_full (size); ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-14 16:00 ` Eli Zaretskii @ 2021-10-14 16:37 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-14 16:43 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-14 16:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50767, alan Eli Zaretskii [2021-10-14 12:01 -0400] wrote: >> From: "Basil L. Contovounesios" <contovob@tcd.ie> >> Cc: Alan Third <alan@idiocy.org>, 50767@debbugs.gnu.org >> Date: Thu, 14 Oct 2021 16:42:24 +0100 >> >> > AFAIR, there's no need to check the return value of xmalloc, because >> > it doesn't return if it cannot allocate memory. >> >> Are you thinking about xalloc? > > No, I'm thinking xmalloc. > >> If not, could you please point me to the part of xmalloc that >> doesn't return (except for the !initialized branch in memory_full)? >> I'm afraid I couldn't spot it. > > This part: > > if (!val && size) > memory_full (size); Sorry, I thought xsignal in memory_full would return, because I confused it with nonlocal exits in dynamic modules which do. Thanks, -- Basil ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-14 16:37 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-14 16:43 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2021-10-14 16:43 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767, alan > From: "Basil L. Contovounesios" <contovob@tcd.ie> > Cc: alan@idiocy.org, 50767@debbugs.gnu.org > Date: Thu, 14 Oct 2021 17:37:23 +0100 > > > if (!val && size) > > memory_full (size); > > Sorry, I thought xsignal in memory_full would return, because I confused > it with nonlocal exits in dynamic modules which do. No need to be sorry. Emacs is tricky. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-09-23 22:49 ` Alan Third 2021-09-23 22:59 ` Alan Third 2021-09-24 6:41 ` Eli Zaretskii @ 2021-10-04 21:45 ` Alan Third 2021-10-14 15:43 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2 siblings, 1 reply; 18+ messages in thread From: Alan Third @ 2021-10-04 21:45 UTC (permalink / raw) To: Basil L. Contovounesios, 50767 [-- Attachment #1: Type: text/plain, Size: 557 bytes --] On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote: > On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote: > > ...which would mean this only holds in the common case that > > face_font_size has fewer than 5 digits, right? > > Looks that way. > > I suppose in this particular case we could limit the font size to a > maximum of 9999 or something, but surely there's a better way of > calculating string sizes? I've implemented a pretty basic check so we shouldn't accidentally overrun the buffer. See attached. -- Alan Third [-- Attachment #2: 0001-Fix-potential-buffer-overflow-bug-50767.patch --] [-- Type: text/x-diff, Size: 2394 bytes --] From 1b2ffac09c184ebc58921f2b48eacc3629596cdb Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Mon, 4 Oct 2021 22:35:41 +0100 Subject: [PATCH] Fix potential buffer overflow (bug#50767) * src/image.c (svg_load_image): Check how many bytes were actually written to the buffer. Don't check xmalloc return value as xmalloc doesn't return if it fails. --- src/image.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/image.c b/src/image.c index 206c7baa2f..49b26301e8 100644 --- a/src/image.c +++ b/src/image.c @@ -9996,10 +9996,16 @@ svg_load_image (struct frame *f, struct image *img, char *contents, if (!STRINGP (lcss)) { /* Generate the CSS for the SVG image. */ - const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}"; - int css_len = strlen (css_spec) + strlen (img->face_font_family); + /* FIXME: The below calculations leave enough space for a font + size up to 9999, if it overflows we just throw an error but + should probably increase the buffer size. */ + const char *css_spec = "svg{font-family:\"%s\";font-size:%dpx}"; + int css_len = strlen (css_spec) + strlen (img->face_font_family) + 1; css = xmalloc (css_len); - snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size); + if (css_len <= snprintf (css, css_len, css_spec, + img->face_font_family, img->face_font_size)) + goto rsvg_error; + rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL); } else @@ -10157,12 +10163,11 @@ svg_load_image (struct frame *f, struct image *img, char *contents, wrapped_contents = xmalloc (buffer_size); - if (!wrapped_contents - || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, - foreground & 0xFFFFFF, width, height, - viewbox_width, viewbox_height, - background & 0xFFFFFF, - SSDATA (encoded_contents))) + if (buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, + foreground & 0xFFFFFF, width, height, + viewbox_width, viewbox_height, + background & 0xFFFFFF, + SSDATA (encoded_contents))) goto rsvg_error; wrapped_size = strlen (wrapped_contents); -- 2.33.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-04 21:45 ` Alan Third @ 2021-10-14 15:43 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-15 17:26 ` Alan Third 2021-11-05 3:13 ` Lars Ingebrigtsen 0 siblings, 2 replies; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-14 15:43 UTC (permalink / raw) To: Alan Third; +Cc: 50767 Alan Third [2021-10-04 22:45 +0100] wrote: > On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote: >> On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote: >> > ...which would mean this only holds in the common case that >> > face_font_size has fewer than 5 digits, right? >> >> Looks that way. >> >> I suppose in this particular case we could limit the font size to a >> maximum of 9999 or something, but surely there's a better way of >> calculating string sizes? > > I've implemented a pretty basic check so we shouldn't accidentally > overrun the buffer. See attached. Thanks, and sorry for the late reply. I haven't had a chance to compile this on armv7l yet, but I should be able to later today or tomorrow. It continues to compile without warnings on x86_64. -- Basil ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-14 15:43 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-15 17:26 ` Alan Third 2021-11-05 3:13 ` Lars Ingebrigtsen 1 sibling, 0 replies; 18+ messages in thread From: Alan Third @ 2021-10-15 17:26 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767 On Thu, Oct 14, 2021 at 04:43:05PM +0100, Basil L. Contovounesios wrote: > Alan Third [2021-10-04 22:45 +0100] wrote: > > > On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote: > >> On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote: > >> > ...which would mean this only holds in the common case that > >> > face_font_size has fewer than 5 digits, right? > >> > >> Looks that way. > >> > >> I suppose in this particular case we could limit the font size to a > >> maximum of 9999 or something, but surely there's a better way of > >> calculating string sizes? > > > > I've implemented a pretty basic check so we shouldn't accidentally > > overrun the buffer. See attached. > > Thanks, and sorry for the late reply. I haven't had a chance to compile > this on armv7l yet, but I should be able to later today or tomorrow. It > continues to compile without warnings on x86_64. I'm not sure it'll silence the warnings, as I'm not sure what we need to do for that, but it should at least reduce the chances of an overflow. -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-10-14 15:43 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-15 17:26 ` Alan Third @ 2021-11-05 3:13 ` Lars Ingebrigtsen 2021-11-06 11:58 ` Alan Third 1 sibling, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-11-05 3:13 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767, Alan Third "Basil L. Contovounesios" <contovob@tcd.ie> writes: > Thanks, and sorry for the late reply. I haven't had a chance to compile > this on armv7l yet, but I should be able to later today or tomorrow. It > continues to compile without warnings on x86_64. This was three weeks ago -- the patch was applied, as far as I can tell? Skimming this thread, it's not quite clear whether there's anything more to do here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-11-05 3:13 ` Lars Ingebrigtsen @ 2021-11-06 11:58 ` Alan Third 2021-11-06 18:20 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Alan Third @ 2021-11-06 11:58 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Basil L. Contovounesios, 50767 On Fri, Nov 05, 2021 at 04:13:55AM +0100, Lars Ingebrigtsen wrote: > "Basil L. Contovounesios" <contovob@tcd.ie> writes: > > > Thanks, and sorry for the late reply. I haven't had a chance to compile > > this on armv7l yet, but I should be able to later today or tomorrow. It > > continues to compile without warnings on x86_64. > > This was three weeks ago -- the patch was applied, as far as I can tell? > Skimming this thread, it's not quite clear whether there's anything more > to do here? I didn't expect my patch to actually silence the warnings. I've no way to find out if it has, either. -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-11-06 11:58 ` Alan Third @ 2021-11-06 18:20 ` Lars Ingebrigtsen 2021-11-14 23:28 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 18:20 UTC (permalink / raw) To: Alan Third; +Cc: Basil L. Contovounesios, 50767 Alan Third <alan@idiocy.org> writes: >> > Thanks, and sorry for the late reply. I haven't had a chance to compile >> > this on armv7l yet, but I should be able to later today or tomorrow. It >> > continues to compile without warnings on x86_64. >> >> This was three weeks ago -- the patch was applied, as far as I can tell? >> Skimming this thread, it's not quite clear whether there's anything more >> to do here? > > I didn't expect my patch to actually silence the warnings. I've no way > to find out if it has, either. Perhaps Basil can check? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-11-06 18:20 ` Lars Ingebrigtsen @ 2021-11-14 23:28 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-11-15 5:53 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-11-14 23:28 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 50767, Alan Third Lars Ingebrigtsen [2021-11-06 19:20 +0100] wrote: > Alan Third <alan@idiocy.org> writes: > >>> > Thanks, and sorry for the late reply. I haven't had a chance to compile >>> > this on armv7l yet, but I should be able to later today or tomorrow. It >>> > continues to compile without warnings on x86_64. >>> >>> This was three weeks ago -- the patch was applied, as far as I can tell? >>> Skimming this thread, it's not quite clear whether there's anything more >>> to do here? >> >> I didn't expect my patch to actually silence the warnings. I've no way >> to find out if it has, either. > > Perhaps Basil can check? Sorry, I won't be able to for a while :(. Feel free to close this bug, and I'll chime back in when I'm at a keyboard again if necessary. Thanks, -- Basil ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l 2021-11-14 23:28 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-11-15 5:53 ` Lars Ingebrigtsen 0 siblings, 0 replies; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-11-15 5:53 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: 50767, Alan Third "Basil L. Contovounesios" <contovob@tcd.ie> writes: > Sorry, I won't be able to for a while :(. Feel free to close this bug, > and I'll chime back in when I'm at a keyboard again if necessary. OK; closing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-11-15 5:53 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-09-23 17:04 bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-09-23 21:46 ` Alan Third 2021-09-23 22:38 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-09-23 22:49 ` Alan Third 2021-09-23 22:59 ` Alan Third 2021-09-24 6:41 ` Eli Zaretskii 2021-10-14 15:42 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-14 16:00 ` Eli Zaretskii 2021-10-14 16:37 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-14 16:43 ` Eli Zaretskii 2021-10-04 21:45 ` Alan Third 2021-10-14 15:43 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-10-15 17:26 ` Alan Third 2021-11-05 3:13 ` Lars Ingebrigtsen 2021-11-06 11:58 ` Alan Third 2021-11-06 18:20 ` Lars Ingebrigtsen 2021-11-14 23:28 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-11-15 5:53 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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.