[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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!


Le samedi, 24 octobre 2020, 14.05:04 h CET Bernhard Übelacker a écrit :
> 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


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: