[sane-devel] canon driver segfault in TPU mode handling

[Ralph Little]

Hi,
Thanks you for your report.

Unfortunately, I don't think we have a maintainer for the canon backend 
at the moment.
I suspect that few people have the capability these days to test 
canon/TPU combinations of this sort which is probably why you are the 
only one to encounter this in recent times.

I will try to have a look at the code sometime but I am not familiar 
with that backend.

Cheers,
Ralph

On 2023-06-25 05:46, Alain Zscheile via sane-devel wrote:
> Hi,
>
> while trying to use a scanner I encountered a segfault
> in simple-scan, which turned out to be caused by the sane-canon 
> backend driver.
>
> backtrace|:||#0 __strlen_sse2 () at 
> ../sysdeps/x86_64/multiarch/strlen-sse2.S:142||||#1 0x00007fe7c722cb02 
> in __GI___strdup (s=0x0) at strdup.c:41||||#2 0x00007fe7a5ca4e57 in 
> init_options (s=s at entry=0x7fe7a01c64d0) at canon.c:1764 #3 
> 0x00007fe7a5ca8be1 in sane_canon_open (devnam=<optimized out>, 
> handle=0x7fe7b4ffea48) at 
> /build/sane-backends-1.2.1/backend/canon-sane.c:205 #4 
> 0x00007fe7c7458ff4 in sane_dll_open (full_name=<optimized out>, 
> meta_handle=meta_handle at entry=0x7fe7b4ffeab0) at dll.c:1294 #5 
> 0x00007fe7c745599e in sane_open (name=<optimized out>, 
> h=h at entry=0x7fe7b4ffeab0) at dll-s.c:27 #6 0x000000000043c897 in 
> scanner_do_open (self=self at entry=0x1485850) at 
> src/simple-scan.p/scanner.c:5419 #7 0x000000000043e0ee in 
> scanner_scan_thread (self=self at entry=0x1485850) at 
> src/simple-scan.p/scanner.c:7320 #8 0x000000000043e12b in 
> _scanner_scan_thread_gthread_func (self=0x1485850) at 
> src/simple-scan.p/scanner.c:7355 #9 0x00007fe7c82ab64d in 
> g_thread_proxy () from 
> /nix/store/cgmbz0wglid7v5m0m0a70ksvgyxppsgn-glib-2.76.3/lib/libglib-2.0.so.0 
> #10 0x00007fe7c7216dd4 in start_thread (arg=<optimized out>) at 
> pthread_create.c:444 #11 0x00007fe7c72989b0 in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81|
>
> In
> https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon.c#L1764 
> <https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon.c#L1764>when|s->hw->tpu.ControlMode 
> is set to 3, `strdup(0)` is called, which|
> |leads to the segfault.|
>
> By now, I applied the following patch,
> in accordance with
> https://gitlab.com/sane-project/backends/-/blob/1.2.1/backend/canon-sane.c#L676 
>
>
> <snip>
> diff --git a/backend/canon.c b/backend/canon.c
> index d17cd01a4..6a0b8aa07 100644
> --- a/backend/canon.c
> +++ b/backend/canon.c
> @@ -166,6 +166,7 @@ static const SANE_String_Const mode_list_fb1200[] = {
>  static const SANE_String_Const tpu_dc_mode_list[] = {
>    SANE_I18N("No transparency correction"),
>    SANE_I18N("Correction according to film type"),
> +  SANE_I18N("Correction according to ??? (unhandled)"),
>    SANE_I18N("Correction according to transparency ratio"),
>    0
>  };
> </snip>
>
> but I don't really know what a proper solution would be...
> ControlMode = 2 doesn't seem to be handled anywhere
> (in contrast to ControlMode = 0,1,3).
>
> This also doesn't seem to be introduced recently, as the related code
> appears to be introduced some 23 years ago, and was last modified 16 
> years
> ago to introduce SANE_I18N...
>
> downstream report: https://github.com/NixOS/nixpkgs/issues/239726
>
> Regards,
> Alain Fogtia Zscheile
>