Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Package: printer-driver-hpcups
Version: 3.20.9+dfsg0-3
Severity: serious
Tags: upstream help

According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz

hpcups sometimes crashes with free(): invalid pointer. For instance, it
seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
printer will let hpcups crash.

I'd welcome assistance here as I'm no C gdb fluent person.


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
APT prefers buildd-unstable
APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages printer-driver-hpcups depends on:
ii cups 2.3.3-3
ii cups-filters [ghostscript-cups] 1.28.5-1
ii libc6 2.31-4
ii libcups2 2.3.3-3
ii libdbus-1-3 1.12.20-1
ii libgcc-s1 10.2.0-15
ii libhpmud0 3.20.9+dfsg0-3
ii libjpeg62-turbo 1:2.0.5-1.1
ii libstdc++6 10.2.0-15
ii zlib1g 1:1.2.11.dfsg-2

printer-driver-hpcups recommends no packages.

Versions of packages printer-driver-hpcups suggests:
pn hplip <none>
pn hplip-doc <none>

-- no debconf information

[Didier 'OdyX' Raboud]

Control: found -1 3.20.5+dfsg0-3
Control: tags -1 +bullseye +upstream

Post by Didier 'OdyX' Raboud
According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz
hpcups sometimes crashes with free(): invalid pointer. For instance, it
seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
printer will let hpcups crash.
I'd welcome assistance here as I'm no C gdb fluent person.

So.

This bug can be reproduced by the following suite of commands on armhf:

$ export PPD=./prnt/hp-officejet_pro_1150c.ppd.gz
$ /usr/lib/cups/filter/pdftopdf 1 debian '' 1 '' </usr/share/cups/data/default-testpage.pdf >print_step_1.pdf
$ /usr/lib/cups/filter/gstoraster 1 debian '' 1 '' <print_step_1.pdf >print_step_2.raster
$ /usr/lib/cups/filter/hpcups 1 debian '' 1 '' <print_step_2.raster >print_step_3.hpcups

As I have confirmed that this is also _already_ a bug in the current bullseye
version, I'll mark this RC bug as affecting the corresponding versions, and
I'll upload a version without the autopkgtest to unstable, to let this version
migrate.

As this is testable at build-time, I'll add a test for this and upload this to
experimental. I'll report this to upstream today.

Cheers,

OdyX

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209

Post by Didier 'OdyX' Raboud
As this is testable at build-time, I'll add a test for this and upload this
to experimental. I'll report this to upstream today.

Damn. It seems the bug doesn't trigger in buildd environments. I have also
tried building hplip on the abel.debian.org porterbox, and the build-time test
doesn't fail there.

So it seems that there's a reproductible bug when run:
- in qemu
- in ci.debian.net's
- in a sid chroot in abel.debian.org


 but not:
- in a buildd build;
- in a manual build in abel.debian.org.

I'm wondering what makes the build process immune to that error.

The attached script will fail in a sid chroot on armhf, and I have reported
this to the upstream bugtracker at
https://bugs.launchpad.net/hplip/+bug/1901209

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue too.

Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.

It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because "mchunk_size" is then 0.

Kind regards,
Bernhard


Old value = 6057
New value = 0
__memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
warning: Source file is more recent than executable.
295 tst count, #4
1: compressBuf = <error: current stack frame does not contain a variable named `this'>
2: /x *(int*)(0x7f5f43e8-4) = 0x0
(gdb) bt
#0 __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
#1 0x7f55b8d2 in memcpy (__len=379, __src=<optimized out>, __dest=<optimized out>) at /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34
#2 Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at prnt/hpcups/Mode9.cpp:405
#3 0x7f562de0 in Pipeline::Process (raster=<optimized out>, this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79
#4 Pipeline::Execute (this=0x7f5d7340, InputRaster=<optimized out>) at prnt/hpcups/Pipeline.cpp:79
#5 0x7f562e02 in Pipeline::Execute (this=0x7f5e6b88, InputRaster=<optimized out>) at prnt/hpcups/Pipeline.cpp:83
#6 0x7f562e02 in Pipeline::Execute (this=0x7f5e6b70, InputRaster=<optimized out>) at prnt/hpcups/Pipeline.cpp:83
#7 0x7f55a20a in HPCupsFilter::processRasterData (this=0x7f5b87c4 <filter>, cups_raster=<optimized out>) at prnt/hpcups/HPCupsFilter.cpp:766
#8 0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 <filter>, argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584
#9 0xb6bd9a20 in __libc_start_main (main=0x7f5587d1 <main(int, char**)>, argc=6, argv=0xbefff7b4, init=<optimized out>, fini=0x7f56ed5d <__libc_csu_fini>, rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at libc-start.c:308
#10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919


https://sources.debian.org/src/hplip/3.20.5+dfsg0-3/prnt/hpcups/Mode9.cpp/#L405

[Didier 'OdyX' Raboud]

Control: found -1 3.21.2+dfsg1-1

Hello there Bernhard,
(CC'ing d-arm for help)

Sadly, I could confirm on a local armhf QEMU instance that this serious bug is
still present, in sid and bullseye; the steps in
https://bugs.debian.org/972339#10 still apply and trigger the SIGABRT.

Although I understand what you're saying in theoretical terms here, I'm
completely at loss to propose a patch: I'm way over my head with my 10+years-
old C and gdb competences. In the absence of any interest from upstream, I
need help to fix hplip on armhf.

(Note that amd64 is apparently also affected; see #974828)

Whoever willing to help; if you need anything from me (as maintainer), please
ask! I'm happy to explain my use of git-debrebase, or provide a different git
history if it helps, I mostly don't want to be in the way of a fix!

Humbly,
OdyX

Post by Bernhard Übelacker
I could reproduce this issue too.
Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.
It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because "mchunk_size" is then 0.
Kind regards,
Bernhard
Old value = 6057
New value = 0
__memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
warning: Source file is more recent than executable.
295 tst count, #4
1: compressBuf = <error: current stack frame does not contain a variable
named `this'> 2: /x *(int*)(0x7f5f43e8-4) = 0x0
(gdb) bt
#0 __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
#1 0x7f55b8d2 in memcpy (__len=379, __src=<optimized out>,
__dest=<optimized out>) at
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34 #2
Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at
prnt/hpcups/Mode9.cpp:405 #3 0x7f562de0 in Pipeline::Process
(raster=<optimized out>, this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79 #4
Pipeline::Execute (this=0x7f5d7340, InputRaster=<optimized out>) at
prnt/hpcups/Pipeline.cpp:79 #5 0x7f562e02 in Pipeline::Execute
(this=0x7f5e6b88, InputRaster=<optimized out>) at
prnt/hpcups/Pipeline.cpp:83 #6 0x7f562e02 in Pipeline::Execute
(this=0x7f5e6b70, InputRaster=<optimized out>) at
prnt/hpcups/Pipeline.cpp:83 #7 0x7f55a20a in
HPCupsFilter::processRasterData (this=0x7f5b87c4 <filter>,
cups_raster=<optimized out>) at prnt/hpcups/HPCupsFilter.cpp:766 #8
0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 <filter>,
argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584 #9 0xb6bd9a20
in __libc_start_main (main=0x7f5587d1 <main(int, char**)>, argc=6,
argv=0xbefff7b4, init=<optimized out>, fini=0x7f56ed5d <__libc_csu_fini>,
rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at libc-start.c:308
#10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919
https://sources.debian.org/src/hplip/3.21.2+dfsg1-1/prnt/hpcups/Mode9.cpp/#L
405

[Debian Bug Tracking System]

Post by Didier 'OdyX' Raboud
found -1 3.20.5+dfsg0-3

Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Marked as found in versions hplip/3.20.5+dfsg0-3.

Post by Didier 'OdyX' Raboud
tags -1 +bullseye +upstream

Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Added tag(s) bullseye.
Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Ignoring request to alter tags of bug #972339 to the same tags previously set

[Debian Bug Tracking System]

forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209

Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Set Bug forwarded-to-address to 'https://bugs.launchpad.net/hplip/+bug/1901209'.

[Paul Gevers]

Dear Didier,

On Fri, 16 Oct 2020 14:23:59 +0200 Didier 'OdyX' Raboud

Post by Didier 'OdyX' Raboud
According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz
hpcups sometimes crashes with free(): invalid pointer. For instance, it
seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
printer will let hpcups crash.

Just to have the information for the release process, do you think this
is a regression compared to buster, or did you just found out now
because of autopkgtest?

Is there any progress on this issue?

Paul

[Debian Bug Tracking System]

tags -1 +help

Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Ignoring request to alter tags of bug #972339 to the same tags previously set

[Debian Bug Tracking System]

Post by Didier 'OdyX' Raboud
found -1 3.21.2+dfsg1-1

Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers
Marked as found in versions hplip/3.21.2+dfsg1-1.

[Debian Bug Tracking System]

Your message dated Fri, 05 Mar 2021 14:18:53 +0000
with message-id <E1lIBI5-000H65-***@fasolo.debian.org>
and subject line Bug#972339: fixed in hplip 3.21.2+dfsg1-2
has caused the Debian Bug report #972339,
regarding armhf: hpcups crashes with free() invalid pointer for some printers
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)

[Didier 'OdyX' Raboud]

Control: unarchive -1

Hello there,

We at openSUSE got a similar (perhaps even same?) issue
https://bugzilla.suse.com/show_bug.cgi?id=1187232
In the end the root cause there was that the installed
HPLIP plugin did not match the installed HPLIP, see
https://bugzilla.suse.com/show_bug.cgi?id=1187232#c8
Perhaps this might also help you with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339
Even if the openSUSE issue is actually a different one
it may help to know that HPLIP programs seem to blindly
use plugin code and may fail in arbitrary ways if the
plugin code does not fit.