Bug 1529372

Summary: Latest json-c update crashes libu2f and pam-u2f
Product: [Fedora] Fedora Reporter: Georg Sauthoff <fedora>
Component: libu2f-hostAssignee: Björn 'besser82' Esser <besser82>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: a.alvarezayllon, besser82, jiri, sethdjennings
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libu2f-host-1.1.3-1.fc26 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-29 20:52:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Georg Sauthoff 2017-12-27 20:36:40 UTC 
Description of problem:
The latest `dnf update` upgraded the json-c library from json-c-0.12.1-2.fc26.x86_64 to 0.12.1-5.fc26.x86_64 (on my system) and the new version yields crashes in libu2f. This breaks user login if the u2f pam module is enabled.


Version-Release number of selected component (if applicable):
json-c-0.12.1-5.fc26.x86_64
pam-u2f-1.0.4-3.fc26.x86_64


How reproducible: always


Steps to Reproduce:
1. u2f-host -a register -o https://memyself.example.org
2. paste: { "challenge": "1", "version": "U2F_V2", "appId": "a"}
3. yield EOT: ENTER, CTRL+D

Actual results:
u2f-host: json_object.c:159: json_object_put: Assertion `jso->_ref_count > 0' failed.
zsh: abort (core dumped)  u2f-host -a register -o https://memyself.example.org

And:

systemd-coredump[4051]: Process 4049 (u2f-host) of user 1000 dumped core.
                                                      
                                                      Stack trace of thread 4049:
                                                      #0  0x00007f247b6ef9fb raise (libc.so.6)
                                                      #1  0x00007f247b6f1800 abort (libc.so.6)
                                                      #2  0x00007f247b6e80da __assert_fail_base (libc.so.6)
                                                      #3  0x00007f247b6e8152 __assert_fail (libc.so.6)
                                                      #4  0x00007f247b2ad26a json_object_put (libjson-c.so.2)
                                                      #5  0x00007f247ba90aad prepare_browserdata (libu2f-host.so.0)
                                                      #6  0x00007f247ba9005f u2fh_register (libu2f-host.so.0)
                                                      #7  0x000055ce9671c44c main (u2f-host)
                                                      #8  0x00007f247b6d988a __libc_start_main (libc.so.6)
                                                      #9  0x000055ce9671c54a _start (u2f-host)


Expected results:
No core dump.

Additional info:
The failure in the pam module is similar, but requires a little bit more effort to setup.

Basically you insert on top of /etc/pam.d/login:

auth requisite pam_u2f.so authfile=/etc/u2f_map interactive debug

See `pamu2fcfg` for details on how the u2f_map should look like.

The core dump then:

systemd-coredump[3721]: Process 3586 (login) of user 0 dumped core.
                                                      
                                                      Stack trace of thread 3586:
                                                      #0  0x00007f6bf47dd9fb raise (libc.so.6)
                                                      #1  0x00007f6bf47df800 abort (libc.so.6)
                                                      #2  0x00007f6bf47d60da __assert_fail_base (libc.so.6)
                                                      #3  0x00007f6bf47d6152 __assert_fail (libc.so.6)
                                                      #4  0x00007f6bf34e826a json_object_put (libjson-c.so.2)
                                                      #5  0x00007f6bf3afeaad prepare_browserdata (libu2f-host.so.0)
                                                      #6  0x00007f6bf3afe40a u2fh_authenticate (libu2f-host.so.0)
                                                      #7  0x00007f6bf3d095d3 do_authentication (pam_u2f.so)
                                                      #8  0x00007f6bf3d0833b pam_sm_authenticate (pam_u2f.so)
                                                      #9  0x00007f6bf51d3e71 _pam_dispatch (libpam.so.0)
                                                      #10 0x00007f6bf51d373b pam_authenticate (libpam.so.0)
                                                      #11 0x00005609eb7b7d7c main (login)
                                                      #12 0x00007f6bf47c788a __libc_start_main (libc.so.6)
                                                      #13 0x00005609eb7b8a8a _start (login)
Comment 1 Björn 'besser82' Esser 2017-12-27 21:54:08 UTC 
Re-assigning to correct component, since this needs to be fixed in libu2f-host…
Comment 2 Fedora Update System 2017-12-27 21:55:08 UTC 
libu2f-host-1.1.3-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-62b71e3ed8
Comment 3 Björn 'besser82' Esser 2017-12-27 22:01:23 UTC 
The mentioned update has been sitting in updates-testing for about 6 months with +2 karma; added this bug and submitted for stable.  Should be pushed into updates-stable within the next 2 days.
Comment 4 Fedora Update System 2017-12-29 20:52:26 UTC 
libu2f-host-1.1.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Comment 5 Georg Sauthoff 2017-12-30 10:06:19 UTC 
I can confirm, with libu2f-host-1.1.3-1.fc26.x86_64 everything works as expected, again.

I'm just wondering why a previous

# dnf --enablerepo=updates-testing install libu2f-host

didn't install the updated version (tested it yesterday, before it was pushed to the stable repository).