View Issue Details

IDProjectCategoryView StatusLast Update
0005754Talerexchangepublic2019-12-20 19:12
ReporterChristian Grothoff Assigned ToChristian Grothoff  
PriorityhighSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.6Fixed in Version0.6 
Summary0005754: libtalerexchange /keys misshandling
DescriptionGiven some odd /keys response, code in exchange_api causes a use after free:

==18260== Invalid read of size 8
==18260== at 0x4A07447: TALER_planchet_to_coin (crypto.c:311)
==18260== by 0x488DC99: reserve_withdraw_ok (exchange_api_reserve.c:758)
==18260== by 0x488E3ED: handle_reserve_withdraw_finished (exchange_api_reserve.c:914)
==18260== by 0x4A10BA4: GNUNET_CURL_perform2 (curl.c:607)
==18260== by 0x4A11268: context_task (curl_reschedule.c:147)
==18260== by 0x4A7C3BA: GNUNET_SCHEDULER_do_work (scheduler.c:2132)
==18260== by 0x4A7D241: select_loop (scheduler.c:2431)
==18260== by 0x4A7785B: GNUNET_SCHEDULER_run (scheduler.c:732)
==18260== by 0x485F385: TALER_TESTING_setup (testing_api_loop.c:817)
==18260== by 0x485C8F4: TALER_TESTING_setup_with_exchange_cfg (testing_api_helpers.c:793)
==18260== by 0x4A32CE2: GNUNET_CONFIGURATION_parse_and_run (configuration.c:170)
==18260== by 0x485C61D: TALER_TESTING_setup_with_exchange (testing_api_helpers.c:697)
==18260== Address 0x96fad30 is 864 bytes inside a block of size 1,440 free'd
==18260== at 0x48369AB: free (vg_replace_malloc.c:530)
==18260== by 0x4A2F9AF: GNUNET_xfree_ (common_allocation.c:339)
==18260== by 0x4A2FD6D: GNUNET_xgrow_ (common_allocation.c:461)
==18260== by 0x487E4EE: free_key_data (exchange_api_handle.c:1060)
==18260== by 0x487F211: keys_completed_cb (exchange_api_handle.c:1323)
==18260== by 0x4A10BA4: GNUNET_CURL_perform2 (curl.c:607)
==18260== by 0x4A11268: context_task (curl_reschedule.c:147)
==18260== by 0x4A7C3BA: GNUNET_SCHEDULER_do_work (scheduler.c:2132)
==18260== by 0x4A7D241: select_loop (scheduler.c:2431)
==18260== by 0x4A7785B: GNUNET_SCHEDULER_run (scheduler.c:732)
==18260== by 0x485F385: TALER_TESTING_setup (testing_api_loop.c:817)
==18260== by 0x485C8F4: TALER_TESTING_setup_with_exchange_cfg (testing_api_helpers.c:793)
==18260== Block was alloc'd at
==18260== at 0x483577F: malloc (vg_replace_malloc.c:299)
==18260== by 0x4A2F68B: GNUNET_xmalloc_unchecked_ (common_allocation.c:232)
==18260== by 0x4A2F027: GNUNET_xmalloc_ (common_allocation.c:75)
==18260== by 0x4A2FCF2: GNUNET_xgrow_ (common_allocation.c:452)
==18260== by 0x487EAD7: keys_completed_cb (exchange_api_handle.c:1218)
==18260== by 0x4A10BA4: GNUNET_CURL_perform2 (curl.c:607)
==18260== by 0x4A11268: context_task (curl_reschedule.c:147)
==18260== by 0x4A7C3BA: GNUNET_SCHEDULER_do_work (scheduler.c:2132)
==18260== by 0x4A7D241: select_loop (scheduler.c:2431)
==18260== by 0x4A7785B: GNUNET_SCHEDULER_run (scheduler.c:732)
==18260== by 0x485F385: TALER_TESTING_setup (testing_api_loop.c:817)
==18260== by 0x485C8F4: TALER_TESTING_setup_with_exchange_cfg (testing_api_helpers.c:793)
==

Basically, it is possible for the /keys handling logic to free /keys still aliased by some other operation in the module.
So we either need to consistently make a copy, or add some complex RC logic.
Steps To ReproduceLook for
    // FIXME: setting 'm' to FOREVER here exposes
    // a crash-bug in lib/ where we access /keys
    // data after it was already free'd!
in taler-exchange-httpd_keystate.c and set m to forever (or change min to max).
Then re-run 'make check' in lib/.
TagsNo tags attached.

Activities

Christian Grothoff

2019-06-06 20:53

manager   ~0014514

Fixed in 69a07468..a4813d18

Issue History

Date Modified Username Field Change
2019-06-05 23:55 Christian Grothoff New Issue
2019-06-05 23:55 Christian Grothoff Status new => assigned
2019-06-05 23:55 Christian Grothoff Assigned To => Christian Grothoff
2019-06-05 23:56 Christian Grothoff View Status private => public
2019-06-06 20:53 Christian Grothoff Note Added: 0014514
2019-06-06 20:53 Christian Grothoff Status assigned => resolved
2019-06-06 20:53 Christian Grothoff Resolution open => fixed
2019-06-06 20:53 Christian Grothoff Fixed in Version => 0.6
2019-12-20 19:12 Christian Grothoff Status resolved => closed