Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crash in pcsc_transmit -> sc_apdu_log -> sc_hex_dump #3138

Closed
jeffallen opened this issue May 8, 2024 · 1 comment
Closed

crash in pcsc_transmit -> sc_apdu_log -> sc_hex_dump #3138

jeffallen opened this issue May 8, 2024 · 1 comment

Comments

@jeffallen
Copy link

jeffallen commented May 8, 2024

Problem Description

I have a repeatable crash of Firefox caused by using a PKCS11 card, then suspending, removing the card, and resuming.

I managed to capture this backtrace:

Thread 8 "Socket Thread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5d412fe6c0 (LWP 66130)]
0x00007f5d4f07b417 in __vfprintf_internal (s=s@entry=0x7f5d412bf230, format=format@entry=0x7f5d0bf7183c "%02X ", ap=ap@entry=0x7f5d412bf370, mode_flags=mode_flags@entry=6)
    at ./stdio-common/vfprintf-internal.c:684
684	./stdio-common/vfprintf-internal.c: No such file or directory.
(gdb) bt
#0  0x00007f5d4f07b417 in __vfprintf_internal (s=s@entry=0x7f5d412bf230, format=format@entry=0x7f5d0bf7183c "%02X ", ap=ap@entry=0x7f5d412bf370, mode_flags=mode_flags@entry=6)
    at ./stdio-common/vfprintf-internal.c:684
#1  0x00007f5d4f0972f7 in __vsprintf_internal
    (string=string@entry=0x7f5cf44f00e0 "", maxlen=maxlen@entry=18446744073709551615, format=0x7f5d0bf7183c "%02X ", args=args@entry=0x7f5d412bf370, mode_flags=mode_flags@entry=6) at ./libio/iovsprintf.c:96
#2  0x00007f5d4f13571d in ___sprintf_chk (s=s@entry=0x7f5cf44f00e0 "", flag=flag@entry=1, slen=slen@entry=18446744073709551615, format=format@entry=0x7f5d0bf7183c "%02X ") at ./debug/sprintf_chk.c:40
#3  0x00007f5d0be2402a in sprintf (__fmt=0x7f5d0bf7183c "%02X ", __s=0x7f5cf44f00e0 "") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:30
#4  sc_hex_dump (len=<optimized out>, buf=<optimized out>, count=<optimized out>, in=0x7f5cf3f28400 "") at ./src/libopensc/log.c:327
#5  sc_hex_dump (in=<optimized out>, count=<optimized out>, buf=<optimized out>, len=<optimized out>) at ./src/libopensc/log.c:311
#6  0x00007f5d0be24181 in _sc_debug_hex
    (ctx=0x7f5d1712d400, type=3, file=0x7f5d0bf79e66 "reader-pcsc.c", line=326, func=0x7f5d0bf792c8 <__FUNCTION__.3> "pcsc_transmit", label=0x7f5d0bf79fb3 "Outgoing APDU", data=0x7f5cf3f28400 "", len=9)
    at ./src/libopensc/log.c:297
#7  0x00007f5d0be59df2 in pcsc_transmit (reader=0x7f5d18c9d3d0, apdu=0x7f5d412bf640) at ./src/libopensc/reader-pcsc.c:326
... etc ...

The code leading up to line 326 is:

	/* encode and log the APDU */
	r = sc_apdu_get_octets(reader->ctx, apdu, &sbuf, &ssize, reader->active_protocol);
	if (r != SC_SUCCESS)
		goto out;
	if (reader->name)
		sc_log(reader->ctx, "reader '%s'", reader->name);
	sc_apdu_log(reader->ctx, sbuf, ssize, 1);                             // line 326

This is why I suspect that sbuf and/or ssize are not valid, causing a crash inside of sc_apdu_log.

On the other hand, I was able to check that sbuf is set to a reasonable pointer, and ssize was 9. So I'm editing the title of this -- I have a different theory, about recursion and stack depth.

Proposed Resolution

Don't crash. :)

No, seriously, I'm going to keep digging and send a PR. Just wanted to write down what I found so far so people know what I'm working on.

Steps to reproduce

I have a repeatable crash of Firefox caused by using a PKCS11 card, then suspending, removing the card, and resuming.

@jeffallen jeffallen changed the title sc_apdu_get_octets can apparently return SC_SUCCESS, but leave buf and size wrong crash in pcsc_transmit -> sc_apdu_log -> sc_hex_dump May 8, 2024
@jeffallen
Copy link
Author

I put a workaround in place for #3139 and this crash stopped. So I'm closing this in favor of the other issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant