Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal
Dear Maintainer,
I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:
http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=completed
This is the dmesg output:
kernel: printers.cgi[3587]: segfault at 0 ip 7f05a859e181 sp
7fffcf0fb678 error 4 in libc-2.28.so[7f05a8464000+148000]
kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84
00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f fd 74 0f
c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1
Unfortunately no core was collected by systemd-coredump, but
I could generate one manually by running it in gdb described in
attached file.
(gdb) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1 0x7f02ba505dae in __GI___strdup (s=0x0) at strdup.c:41
#2 0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11
"job_name", element=element@entry=0) at var.c:171
#3 0x556d4f023cdc in cgi_copy (out=out@entry=0x7f02ba63a760
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0,
term=term@entry=125 '}', indent=indent@entry=4) at template.c:299
#4 0x556d4f0245fe in cgi_copy (out=out@entry=0x7f02ba63a760
<_IO_2_1_stdout_>, in=in@entry=0x556d4f068590, element=element@entry=0,
term=term@entry=125 '}', indent=indent@entry=2) at template.c:348
#5 0x556d4f023ee6 in cgi_copy (out=0x7f02ba63a760 <_IO_2_1_stdout_>,
in=in@entry=0x556d4f068590, element=element@entry=0, term=term@entry=0 '\000',
indent=indent@entry=0) at template.c:602
#6 0x556d4f024977 in cgiCopyTemplateLang
(tmpl=tmpl@entry=0x556d4f027091 "jobs.tmpl") at template.c:148
#7 0x556d4f02206e in cgiShowJobs (http=,
dest=0x7fffd5510ee0 "Samsung_CLX-3180_Series") at ipp-var.c:1506
#8 0x556d4f01f9e6 in show_printer (printer=0x7fffd5510ee0
"Samsung_CLX-3180_Series", http=0x556d4f06c370) at printers.c:540
#9 main () at printers.c:137
...
(gdb) up
#2 0x556d4f025055 in cgiGetArray (name=name@entry=0x7fffd550ce11
"job_name", element=element@entry=0) at var.c:171
171 return (strdup(var->values[element]));
I found an upstream change that leaves cgiGetArray
if "var->values[element]" would be a NULL value [1].
This change reached bullseye/testing already, therefore
just buster/stable would be affected [2].
But I am not sure if this is the real problem as the
file /var/spool/cups/c00208 really contains a "job-name",
but no "job_name".
My guess is the "job_name" originates from
/usr/share/cups/templates/de/jobs.tmpl.
Therefore might this be a internationalisation issue?
A package cups built with the patch in [1] makes the
finished jobs page load completely.
All print jobs show as name unknown ("Unbekannt"),
except some recent test pages.
Most regular prints are done from a kde environment e.g. okular.
So maybe this upstream patch is worth to be considered in stable?
And second, can someone confirm if this unknown name is an issue,
while the file in /var/spool/cups does contain a job-name?
When opening the kde print queue I get the job names - maybe it
is changed to unknown on purpose for security reasons?
In bullseye/testing the web page shows also unknown, even
when credentials were given before and test page is printed
from there. (Should this go into a separate bug?)
Kind regards,
Bernhard
[1]
https://github.com/apple/cups/commit/eda46e3aac94d42e4199d95befe99ff83afb098f
https://github.com/apple/cups/pull/5621
[2] https://sources.debian.org/src/cups/2.2.10-6+deb10u2/cgi-bin/var.c/#L171
https://sources.debian.org/src/cups/2.3.1-11/cgi-bin/var.c/#L173
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cups depends on:
ii cups-client2.2.10-6+deb10u2
ii cups-common2.2.10-6+deb10u2
ii cups-core-drivers 2.2.10-6+deb10u2
ii cups-daemon2.2.10-6+deb10u2
ii cups-filters 1.21.6-5
ii cups-ppdc 2.2.10-6+deb10u2
ii cups-server-common 2.2.10-6+deb10u2
ii debconf [debconf-2.0] 1.5.71
ii ghostscript9.27~dfsg-2+deb10u3
ii libavahi-client3 0.7-4+b1
ii libavahi-common3 0.7-4+b1
ii libc6 2.28-10
ii libcups2 2.2.10-6+deb10u2
ii libcupsimage2 2.2.10-6+deb10u2
ii libgcc1