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.

Sign up for GitHub

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

Jump to bottom

'oval eval' does not work properly in version 0.9.3 (RHEL) but does in v1.0.8 #3

Closed
gregelin opened this issue Sep 8, 2014 · 3 comments
Closed

'oval eval' does not work properly in version 0.9.3 (RHEL) but does in v1.0.8 #3

gregelin opened this issue Sep 8, 2014 · 3 comments

Comments

@gregelin
Copy link

gregelin commented Sep 8, 2014

Is it correct that oscap oval eval is broken in OpenSCAP version 0.9.3?

On RHEL64 (no yum update) OpenSCAP appears to be version 0.9.3. For rule umask_for_daemons oscap oval eval does not indicate failure.

[root@vagrant fisma3]# oscap oval eval --id oval:ssg:def:221 --variables scans/variables.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-oval.xml
Evaluation done.
[root@vagrant fisma3]# echo $?
0

Subscribing the system to RedHat and updating openscap provides more expected results for oscap oval eval

[root@vagrant fisma3]# oscap oval eval --id oval:ssg:def:221 --variables scans/variables.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-oval.xml
Definition oval:ssg:def:221: false
Evaluation done.

CentOS65 with OpenSCAP version 1.0.8, doing oscap oval eval for umask_for_daemons responds:

oscap oval eval --id oval:ssg:def:221 --variables scans/variables.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-oval.xml
Definition oval:ssg:def:221: false
Evaluation done.
[root@vagrant fismacentos1]# echo $?
0
@gregelin gregelin mentioned this issue Sep 8, 2014
Open
@isimluk
Copy link
Member

isimluk commented Sep 8, 2014

Hey Greg,

There is no bug in OpenSCAP. OpenSCAP oval eval works properly even with 0.9.3. You can use --oval-results option to see result of the definition evaluation.

The thing is that, version 0.9.3 does not print out the result. The print out was introduced in 109d299.

@isimluk isimluk closed this as completed Sep 8, 2014
@gregelin
Copy link
Author

gregelin commented Sep 8, 2014

--oval-results in 0.9.3 and --results in 1.0.8?

I could only get scap oval eval --id oval:ssg:def:221 --variables scans/variables.xml --results file.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-oval.xml to work in 1.0.8.

That command prints out 1MB file with everything in it. That seems like
overkill for a single oval test. Just want to make sure I am doing
correctly.

The command line printout of the results is terrific. Thanks for clarifying.

Greg

On Mon, Sep 8, 2014 at 8:14 AM, Šimon Lukašík notifications@github.com
wrote:

Hey Greg,

There is no bug in OpenSCAP. OpenSCAP oval eval works properly even with
0.9.3. You can use --oval-results option to see result of the definition
evaluation.

The thing is that, version 0.9.3 does not print out the result. The print
out was introduced in 109d299
109d299
.

—
Reply to this email directly or view it on GitHub
#3 (comment).

isimluk added a commit to isimluk/openscap that referenced this issue Sep 10, 2014
@isimluk
Do not pass NULL to strregcomp
b45feaf 
xmlWalkerReader may give us NULL where we used to get "" from
xmlTextReader

Addressing:
 OpenSCAP#1  0x00007ffff7d5cd3b in strregcomp (pattern=0x629a70 ".*", test_str=0x0)
	at oval_cmp_basic.c:143
 OpenSCAP#2  0x00007ffff7d5cecf in oval_string_cmp (state=0x629a70 ".*", syschar=0x0,
	operation=OVAL_OPERATION_PATTERN_MATCH) at oval_cmp_basic.c:192
 OpenSCAP#3  0x00007ffff7d5c362 in oval_ent_cmp_str (state_data=0x629a70 ".*",
	state_data_type=OVAL_DATATYPE_STRING, sysent=0x62a210,
	operation=OVAL_OPERATION_PATTERN_MATCH) at oval_cmp.c:99
 OpenSCAP#4  0x00007ffff7d64a44 in _evaluate_sysent (syschar_model=0x61c870,
	item_entity=0x62a210, state_entity=0x6299c0,
	state_entity_operation=OVAL_OPERATION_PATTERN_MATCH,
	content=0x629970) at oval_resultTest.c:464
 OpenSCAP#5  0x00007ffff7d64cd5 in eval_item (syschar_model=0x61c870,
	cur_sysitem=0x61f200, state=0x61fab0) at oval_resultTest.c:546
 OpenSCAP#6  0x00007ffff7d65021 in eval_check_state (test=0x627d60,
	args=0x7fffffffd600) at oval_resultTest.c:644
 OpenSCAP#7  0x00007ffff7d6553a in _oval_result_test_evaluate_items
	(test=0x627d60, syschar_object=0x61e180, args=0x7fffffffd600)
	at oval_resultTest.c:805
 OpenSCAP#8  0x00007ffff7d65765 in _oval_result_test_result (rtest=0x62a770,
	args=0x7fffffffd600) at oval_resultTest.c:870
 OpenSCAP#9  0x00007ffff7d65af4 in oval_result_test_eval (rtest=0x62a770) at
	oval_resultTest.c:966
 OpenSCAP#10 0x00007ffff7d5f907 in _oval_result_criteria_node_result
	(node=0x62d510) at oval_resultCriteriaNode.c:357
 OpenSCAP#11 0x00007ffff7d5f99f in oval_result_criteria_node_eval (node=0x62d510)
	at oval_resultCriteriaNode.c:378
 OpenSCAP#12 0x00007ffff7d5f8a5 in _oval_result_criteria_node_result
	(node=0x61e1e0) at oval_resultCriteriaNode.c:348
@mpreisler
Copy link
Member

Hi,
--oval-results and --results are 2 completely different options. Please refer to the man page.

isimluk added a commit that referenced this issue Mar 11, 2015
@isimluk
Fix segfault on invalid xccdf:refine-value selector.
dd94c23 
Addressing:
 #0 in xccdf_value_instance_get_value (item=0x0) at value.c:437
 #1 in xccdf_policy_get_value_of_item (policy=0x630a00, item=0x63ad80) at xccdf_policy.c:2426
 #2 in xccdf_policy_add_final_setvalue (policy=0x630a00, value=0x63ad80, result=0x630870) at xccdf_policy.c:2193
 #3 in xccdf_policy_add_final_setvalues (policy=0x630a00, item=0x631d90, result=0x630870) at xccdf_policy.c:2228
 #4 in xccdf_policy_evaluate (policy=0x630a00) at xccdf_policy.c:2318
 #5 in xccdf_session_evaluate (session=0x61fb00) at xccdf_session.c:907
 #6 in app_evaluate_xccdf (action=0x7fffffffd4a0) at oscap-xccdf.c:490
 #7 in oscap_module_call (action=0x7fffffffd4a0) at oscap-tool.c:261
 #8 in oscap_module_process (module=0x6176c0 <XCCDF_EVAL>, argc=8, argv=0x7fffffffd718) at oscap-tool.c:346
 #9 in main (argc=8, argv=0x7fffffffd718) at oscap.c:79
isimluk added a commit that referenced this issue Apr 15, 2015
@isimluk
trac#458: Avoid double free
4fd23e1 
These hunks are missing from 41ef893.

Addressing segmentation fault:
 #0  0x00007ffff561108d in xmlHashFree () from /lib64/libxml2.so.2
 #1  0x00007ffff560865c in xmlFreeDoc () from /lib64/libxml2.so.2
 #2  0x00007ffff7ad39f8 in oscap_source_free (source=0xf45e90) at oscap_source.c:109
 #3  0x00007ffff7ace116 in oscap_htable_free (htable=0xd7dd90, destructor=0x7ffff7ad3968 <oscap_source_free>) at list.c:532
 #4  0x00007ffff7b6f79f in _xccdf_session_free_oval_result_sources (session=0x61fb40) at xccdf_session.c:1023
 #5  0x00007ffff7b6cf73 in xccdf_session_free (session=0x61fb40) at xccdf_session.c:205
 #6  0x000000000040bfe4 in app_evaluate_xccdf (action=0x7fffffffd430) at oscap-xccdf.c:540
 #7  0x0000000000407f8b in oscap_module_call (action=0x7fffffffd430) at oscap-tool.c:260
 #8  0x0000000000408408 in oscap_module_process (module=0x617700 <XCCDF_EVAL>, argc=12, argv=0x7fffffffd6a8) at oscap-tool.c:345
 #9  0x0000000000406e1d in main (argc=12, argv=0x7fffffffd6a8) at oscap.c:80
isimluk added a commit that referenced this issue Jun 18, 2015
@isimluk
rhbz#1220944: Fix crash on invalid value selectors
f99c557 
Addressing:
 #0  xccdf_value_instance_get_value (item=0x0) at value.c:437
 #1  0x00007f6835881eac in xccdf_policy_get_value_of_item (policy=policy@entry=0x7f68371a1b10, item=<optimized out>) at xccdf_policy.c:2426
 #2  0x00007f6835881f01 in xccdf_policy_add_final_setvalue (policy=policy@entry=0x7f68371a1b10, value=0x7f6836f8bbb0, result=result@entry=0x7f6837850d80) at xccdf_policy.c:2193
 #3  0x00007f6835881fa3 in xccdf_policy_add_final_setvalues (policy=policy@entry=0x7f68371a1b10, item=0x7f6836f8a040, result=result@entry=0x7f6837850d80) at xccdf_policy.c:2213
 #4  0x00007f6835881fe3 in xccdf_policy_add_final_setvalues (policy=policy@entry=0x7f68371a1b10, item=0x7f6836f1f280, result=result@entry=0x7f6837850d80) at xccdf_policy.c:2220
 #5  0x00007f6835881fe3 in xccdf_policy_add_final_setvalues (policy=policy@entry=0x7f68371a1b10, item=0x7f6836e57630, result=result@entry=0x7f6837850d80) at xccdf_policy.c:2220
 #6  0x00007f6835882083 in xccdf_policy_add_final_setvalues (policy=policy@entry=0x7f68371a1b10, item=0x7f6836e186c0, result=result@entry=0x7f6837850d80) at xccdf_policy.c:2235
 #7  0x00007f683588220d in xccdf_policy_evaluate (policy=policy@entry=0x7f68371a1b10) at xccdf_policy.c:2318
 #8  0x00007f683587ddea in xccdf_session_evaluate (session=session@entry=0x7f6836d00b60) at xccdf_session.c:906
 #9  0x00007f6835cf4210 in app_evaluate_xccdf (action=0x7fff67b1c800) at oscap-xccdf.c:490
 #10 0x00007f6835cefc69 in oscap_module_call (action=0x7fff67b1c800) at oscap-tool.c:261
 #11 oscap_module_process (module=0x7f6835efdb60 <XCCDF_EVAL>, module@entry=0x7f6835efd0e0 <OSCAP_ROOT_MODULE>, argc=argc@entry=8, argv=argv@entry=0x7fff67b1ca88) at oscap-tool.c:346
 #12 0x00007f6835cee9b1 in main (argc=8, argv=0x7fff67b1ca88) at oscap.c:79
@ybznek ybznek mentioned this issue Jul 29, 2015
Merged
jlcharton added a commit to jlcharton/openscap that referenced this issue Sep 5, 2017
@jlcharton
Update oscap-oval.c
e3876f2 
Fix the following warning raised by Oracle Developer Studio 12.5:
  CC       oscap-oscap-oval.o
"oscap-oval.c", line 361: warning: improper pointer/integer combination: arg OpenSCAP#3.
@jlcharton jlcharton mentioned this issue Sep 5, 2017
Merged
jlcharton added a commit to jlcharton/openscap that referenced this issue Sep 22, 2017
@jlcharton
Update oscap-oval.c
766b5e1 
Fix the following warning raised by Oracle Developer Studio 12.5:
  CC       oscap-oscap-oval.o
"oscap-oval.c", line 361: warning: improper pointer/integer combination: arg OpenSCAP#3.
jan-cerny added a commit to jan-cerny/openscap that referenced this issue Oct 24, 2018
@jan-cerny
RHBZ#1642283: Segmentation fault in CVRF
c28e076 
Addressing:
```
 #0  0x00007ffff4b486e9 in cvrf_model_filter_by_cpe (model=0x0,
    cpe=0x600c0000bde0 "Red Hat Enterprise Linux Desktop Supplementary
(v. 6)")
    at cvrf_priv.c:1293
 #1  0x00007ffff4b4d35e in find_all_cvrf_product_ids_from_cpe (
    session=session@entry=0x60080000a4d0) at cvrf_eval.c:172
 OpenSCAP#2  0x00007ffff4b4debe in cvrf_model_get_results_source
(import_source=<optimized out>,
    os_name=os_name@entry=0x555555584660 "Red Hat Enterprise Linux
Desktop Supplementary (v. 6)") at cvrf_eval.c:230
 OpenSCAP#3  0x0000555555574c58 in app_cvrf_evaluate (action=0x7fffffffe2c0) at
oscap-cvrf.c:102
 OpenSCAP#4  0x0000555555566e16 in oscap_module_call (action=0x7fffffffe2c0) at
oscap-tool.c:261
 OpenSCAP#5  oscap_module_process (module=0x55555578ffc0 <CVRF_EVALUATE_MODULE>,
    module@entry=0x55555578a120 <OSCAP_ROOT_MODULE>, argc=argc@entry=4,
    argv=argv@entry=0x7fffffffe5b8) at oscap-tool.c:346
 OpenSCAP#6  0x0000555555564c32 in main (argc=4, argv=0x7fffffffe5b8) at
oscap.c:83
```
jan-cerny added a commit to jan-cerny/openscap that referenced this issue Oct 24, 2018
@jan-cerny
RHBZ#1642283: Segmentation fault in CVRF
30f52e3 
Addressing:
```
 #0  0x00007ffff4b486e9 in cvrf_model_filter_by_cpe (model=0x0,
    cpe=0x600c0000bde0 "Red Hat Enterprise Linux Desktop Supplementary
(v. 6)")
    at cvrf_priv.c:1293
 #1  0x00007ffff4b4d35e in find_all_cvrf_product_ids_from_cpe (
    session=session@entry=0x60080000a4d0) at cvrf_eval.c:172
 OpenSCAP#2  0x00007ffff4b4debe in cvrf_model_get_results_source
(import_source=<optimized out>,
    os_name=os_name@entry=0x555555584660 "Red Hat Enterprise Linux
Desktop Supplementary (v. 6)") at cvrf_eval.c:230
 OpenSCAP#3  0x0000555555574c58 in app_cvrf_evaluate (action=0x7fffffffe2c0) at
oscap-cvrf.c:102
 OpenSCAP#4  0x0000555555566e16 in oscap_module_call (action=0x7fffffffe2c0) at
oscap-tool.c:261
 OpenSCAP#5  oscap_module_process (module=0x55555578ffc0 <CVRF_EVALUATE_MODULE>,
    module@entry=0x55555578a120 <OSCAP_ROOT_MODULE>, argc=argc@entry=4,
    argv=argv@entry=0x7fffffffe5b8) at oscap-tool.c:346
 OpenSCAP#6  0x0000555555564c32 in main (argc=4, argv=0x7fffffffe5b8) at
oscap.c:83
```
@rodcollins rodcollins mentioned this issue Jul 18, 2022
Closed
maage added a commit to maage/openscap that referenced this issue Sep 4, 2022
@maage
bugfix: xinetd_probe: inmem needs space for \0 at end
5cc71dd 
TEST: test_probe_xinetd_duplicates
=================================================================
==865597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000001d4d at pc 0x7f78bcc4c87c bp 0x7ffdcac81740 sp 0x7ffdcac80ef0
READ of size 974 at 0x619000001d4d thread T0
    #0 0x7f78bcc4c87b in __interceptor_strchr.part.0 (/lib64/libasan.so.8+0x4c87b)
    OpenSCAP#1 0x564e304c23e2 in xiconf_parse /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../sr
c/OVAL/probes/unix/xinetd_probe.c:633
    OpenSCAP#2 0x564e304ba8e5 in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xinetd/test_probe_xinetd.c:40
    OpenSCAP#3 0x7f78bc42954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)
    OpenSCAP#4 0x7f78bc429608 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x29608)
    OpenSCAP#5 0x564e304baed4 in _start (/builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/redhat-linux-build/tests/probes/xinetd/tes
t_probe_xinetd+0x4ed4)

0x619000001d4d is located 0 bytes to the right of 973-byte region [0x619000001980,0x619000001d4d)
allocated by thread T0 here:
    #0 0x7f78bccba68f in __interceptor_malloc (/lib64/libasan.so.8+0xba68f)
    OpenSCAP#1 0x564e304c1a87 in xiconf_read /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../src
/OVAL/probes/unix/xinetd_probe.c:525
    OpenSCAP#2 0x564e304c226c in xiconf_parse /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../sr
c/OVAL/probes/unix/xinetd_probe.c:608
    OpenSCAP#3 0x564e304ba8e5 in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xinetd/test_probe_xinetd.c:40
    OpenSCAP#4 0x7f78bc42954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x4c87b) in __interceptor_strchr.part.0
Shadow bytes around the buggy address:
  0x0c327fff8350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fff83a0: 00 00 00 00 00 00 00 00 00[05]fa fa fa fa fa fa
  0x0c327fff83b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==865597==ABORTING
maage added a commit to maage/openscap that referenced this issue Sep 4, 2022
@maage
bugfix: xmlfilecontent_probe: process_file ptr mixup
921f1be 
libxml2 does use <= when comparing nodeNr and 0.

node line depends on node type, we need to use function to find it.
See: https://github.com/tenderlove/libxml2/blob/ecb5d5afdc8acceba608524f6e98c361fd2ce0e9/tree.c#L4507

253/265 Test: probes/xmlfilecontent/test_xmlfilecontent_probe.sh
Command: "/builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xmlfilecontent/test_xmlfilecontent_probe.sh"
Directory: /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/redhat-linux-build/tests/probes/xmlfilecontent
"probes/xmlfilecontent/test_xmlfilecontent_probe.sh" start time: Sep 04 20:13 EEST
Output:
----------------------------------------------------------
=================================================================
==866168==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6080003efd90 at pc 0x7fdbf2623c59 bp 0x7fdbe7ab8430 sp 0x7fdbe7ab8428
READ of size 2 at 0x6080003efd90 thread T8
    #0 0x7fdbf2623c58 in process_file.isra.0 /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independent/xm
lfilecontent_probe.c:307
    OpenSCAP#1 0x7fdbf25dba5a in xmlfilecontent_probe_main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independ
ent/xmlfilecontent_probe.c:397
    OpenSCAP#2 0x7fdbf25c2087 in probe_worker /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/worker.c:1114
    OpenSCAP#3 0x7fdbf25bc44f in probe_worker_runfn /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/worker.c:
97
    OpenSCAP#4 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)
    OpenSCAP#5 0x7fdbf21121af in clone3 (/lib64/libc.so.6+0x1121af)

0x6080003efd90 is located 16 bytes to the right of 96-byte region [0x6080003efd20,0x6080003efd80)
allocated by thread T8 here:
    #0 0x7fdbf28ba68f in __interceptor_malloc (/lib64/libasan.so.8+0xba68f)
    OpenSCAP#1 0x7fdbf22cdb63 in xmlNewPropInternal.lto_priv.0 (/lib64/libxml2.so.2+0x57b63)

Thread T8 created by T7 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf25bf673 in probe_input_handler /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/input_handler.c:183
    OpenSCAP#2 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)

Thread T7 created by T5 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf25be1d0 in probe_common_main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/probe_main.c:256
    OpenSCAP#2 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)

Thread T5 created by T0 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf253b6a0 in sch_queue_connect /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/SEAP/sch_queue.c:62
    OpenSCAP#2 0x7fdbf253b6a0 in SEAP_connect /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/SEAP/seap.c:116
    OpenSCAP#3 0x7fdbf253b6a0 in oval_probe_comm /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:443
    OpenSCAP#4 0x7fdbf2543e1d in oval_probe_ext_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:980
    OpenSCAP#5 0x7fdbf2543e1d in oval_probe_ext_handler /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:858
    OpenSCAP#6 0x7fdbf2545af4 in oval_probe_query_object /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe.c:156
    OpenSCAP#7 0x7fdbf255bf83 in oval_probe_query_test /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe.c:257
    OpenSCAP#8 0x7fdbf255bf83 in _oval_result_test_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultTest.c:1031
    OpenSCAP#9 0x7fdbf255bf83 in oval_result_test_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultTest.c:1152
    OpenSCAP#10 0x7fdbf255c67f in _oval_result_criteria_node_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:367
    OpenSCAP#11 0x7fdbf255c67f in oval_result_criteria_node_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:390
    OpenSCAP#12 0x7fdbf255c61c in _oval_result_criteria_node_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:358
    OpenSCAP#13 0x7fdbf255c61c in oval_result_criteria_node_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:390
    OpenSCAP#14 0x7fdbf255c835 in oval_result_definition_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultDefinition.c:165
    OpenSCAP#15 0x7fdbf255cae8 in oval_result_system_eval_definition /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultSystem.c:373
    OpenSCAP#16 0x7fdbf2502951 in oval_agent_eval_system /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_agent.c:286
    OpenSCAP#17 0x7fdbf250ac0b in oval_session_evaluate /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_session.c:372
    OpenSCAP#18 0x55cf5fd8b858 in app_evaluate_oval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-oval.c:360
    OpenSCAP#19 0x55cf5fd94b86 in oscap_module_call /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-tool.c:295
    OpenSCAP#20 0x55cf5fd94b86 in oscap_module_process /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-tool.c:389
    OpenSCAP#21 0x55cf5fd81d4e in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap.c:88
    OpenSCAP#22 0x7fdbf202954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independent/xmlfilecontent_probe.c:307 in process_file.isra.0
Shadow bytes around the buggy address:
  0x0c1080075f60: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f70: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f80: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f90: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fa0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1080075fb0: fa fa[fa]fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fc0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fd0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fe0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075ff0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1080076000: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==866168==ABORTING
maage added a commit to maage/openscap that referenced this issue Sep 12, 2022
@maage
bugfix: xinetd_probe: inmem needs space for \0 at end
2a45a6d 
TEST: test_probe_xinetd_duplicates
=================================================================
==865597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000001d4d at pc 0x7f78bcc4c87c bp 0x7ffdcac81740 sp 0x7ffdcac80ef0
READ of size 974 at 0x619000001d4d thread T0
    #0 0x7f78bcc4c87b in __interceptor_strchr.part.0 (/lib64/libasan.so.8+0x4c87b)
    OpenSCAP#1 0x564e304c23e2 in xiconf_parse /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../sr
c/OVAL/probes/unix/xinetd_probe.c:633
    OpenSCAP#2 0x564e304ba8e5 in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xinetd/test_probe_xinetd.c:40
    OpenSCAP#3 0x7f78bc42954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)
    OpenSCAP#4 0x7f78bc429608 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x29608)
    OpenSCAP#5 0x564e304baed4 in _start (/builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/redhat-linux-build/tests/probes/xinetd/tes
t_probe_xinetd+0x4ed4)

0x619000001d4d is located 0 bytes to the right of 973-byte region [0x619000001980,0x619000001d4d)
allocated by thread T0 here:
    #0 0x7f78bccba68f in __interceptor_malloc (/lib64/libasan.so.8+0xba68f)
    OpenSCAP#1 0x564e304c1a87 in xiconf_read /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../src
/OVAL/probes/unix/xinetd_probe.c:525
    OpenSCAP#2 0x564e304c226c in xiconf_parse /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/public/../../../../sr
c/OVAL/probes/unix/xinetd_probe.c:608
    OpenSCAP#3 0x564e304ba8e5 in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xinetd/test_probe_xinetd.c:40
    OpenSCAP#4 0x7f78bc42954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x4c87b) in __interceptor_strchr.part.0
Shadow bytes around the buggy address:
  0x0c327fff8350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fff83a0: 00 00 00 00 00 00 00 00 00[05]fa fa fa fa fa fa
  0x0c327fff83b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff83f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==865597==ABORTING
maage added a commit to maage/openscap that referenced this issue Sep 12, 2022
@maage
bugfix: xmlfilecontent_probe: process_file ptr mixup
b362ca7 
libxml2 does use <= when comparing nodeNr and 0.

node line depends on node type, we need to use function to find it.
See: https://github.com/tenderlove/libxml2/blob/ecb5d5afdc8acceba608524f6e98c361fd2ce0e9/tree.c#L4507

253/265 Test: probes/xmlfilecontent/test_xmlfilecontent_probe.sh
Command: "/builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/tests/probes/xmlfilecontent/test_xmlfilecontent_probe.sh"
Directory: /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/redhat-linux-build/tests/probes/xmlfilecontent
"probes/xmlfilecontent/test_xmlfilecontent_probe.sh" start time: Sep 04 20:13 EEST
Output:
----------------------------------------------------------
=================================================================
==866168==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6080003efd90 at pc 0x7fdbf2623c59 bp 0x7fdbe7ab8430 sp 0x7fdbe7ab8428
READ of size 2 at 0x6080003efd90 thread T8
    #0 0x7fdbf2623c58 in process_file.isra.0 /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independent/xm
lfilecontent_probe.c:307
    OpenSCAP#1 0x7fdbf25dba5a in xmlfilecontent_probe_main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independ
ent/xmlfilecontent_probe.c:397
    OpenSCAP#2 0x7fdbf25c2087 in probe_worker /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/worker.c:1114
    OpenSCAP#3 0x7fdbf25bc44f in probe_worker_runfn /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/worker.c:
97
    OpenSCAP#4 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)
    OpenSCAP#5 0x7fdbf21121af in clone3 (/lib64/libc.so.6+0x1121af)

0x6080003efd90 is located 16 bytes to the right of 96-byte region [0x6080003efd20,0x6080003efd80)
allocated by thread T8 here:
    #0 0x7fdbf28ba68f in __interceptor_malloc (/lib64/libasan.so.8+0xba68f)
    OpenSCAP#1 0x7fdbf22cdb63 in xmlNewPropInternal.lto_priv.0 (/lib64/libxml2.so.2+0x57b63)

Thread T8 created by T7 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf25bf673 in probe_input_handler /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/input_handler.c:183
    OpenSCAP#2 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)

Thread T7 created by T5 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf25be1d0 in probe_common_main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/probe/probe_main.c:256
    OpenSCAP#2 0x7fdbf208ce2c in start_thread (/lib64/libc.so.6+0x8ce2c)

Thread T5 created by T0 here:
    #0 0x7fdbf284b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    OpenSCAP#1 0x7fdbf253b6a0 in sch_queue_connect /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/SEAP/sch_queue.c:62
    OpenSCAP#2 0x7fdbf253b6a0 in SEAP_connect /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/SEAP/seap.c:116
    OpenSCAP#3 0x7fdbf253b6a0 in oval_probe_comm /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:443
    OpenSCAP#4 0x7fdbf2543e1d in oval_probe_ext_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:980
    OpenSCAP#5 0x7fdbf2543e1d in oval_probe_ext_handler /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe_ext.c:858
    OpenSCAP#6 0x7fdbf2545af4 in oval_probe_query_object /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe.c:156
    OpenSCAP#7 0x7fdbf255bf83 in oval_probe_query_test /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_probe.c:257
    OpenSCAP#8 0x7fdbf255bf83 in _oval_result_test_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultTest.c:1031
    OpenSCAP#9 0x7fdbf255bf83 in oval_result_test_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultTest.c:1152
    OpenSCAP#10 0x7fdbf255c67f in _oval_result_criteria_node_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:367
    OpenSCAP#11 0x7fdbf255c67f in oval_result_criteria_node_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:390
    OpenSCAP#12 0x7fdbf255c61c in _oval_result_criteria_node_result /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:358
    OpenSCAP#13 0x7fdbf255c61c in oval_result_criteria_node_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultCriteriaNode.c:390
    OpenSCAP#14 0x7fdbf255c835 in oval_result_definition_eval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultDefinition.c:165
    OpenSCAP#15 0x7fdbf255cae8 in oval_result_system_eval_definition /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/results/oval_resultSystem.c:373
    OpenSCAP#16 0x7fdbf2502951 in oval_agent_eval_system /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_agent.c:286
    OpenSCAP#17 0x7fdbf250ac0b in oval_session_evaluate /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/oval_session.c:372
    OpenSCAP#18 0x55cf5fd8b858 in app_evaluate_oval /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-oval.c:360
    OpenSCAP#19 0x55cf5fd94b86 in oscap_module_call /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-tool.c:295
    OpenSCAP#20 0x55cf5fd94b86 in oscap_module_process /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap-tool.c:389
    OpenSCAP#21 0x55cf5fd81d4e in main /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/utils/oscap.c:88
    OpenSCAP#22 0x7fdbf202954f in __libc_start_call_main (/lib64/libc.so.6+0x2954f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /builddir/build/BUILD/openscap-f81da4bd66dbe528ffa6be16aca36b93f3eec0a5/src/OVAL/probes/independent/xmlfilecontent_probe.c:307 in process_file.isra.0
Shadow bytes around the buggy address:
  0x0c1080075f60: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f70: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f80: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075f90: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fa0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1080075fb0: fa fa[fa]fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fc0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fd0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075fe0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1080075ff0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1080076000: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==866168==ABORTING
jan-cerny added a commit to jan-cerny/openscap that referenced this issue May 9, 2023
@jan-cerny
Plug a memory leak
1c2863c 
When there already exists a value under the given key in the
hash table, oscap_htable_add doesn't put the value to the hash table
and therefore the value isn't freed when the hash table is freed.
The caller of oscap_htable_add needs to check if oscap_htable_add
failed and in this situation is responsible to free the value.

Addressing:

oscap  xccdf eval --profile '(all)' --rule xccdf_org.ssgproject.content_rule_accounts_tmout /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
--- Starting Evaluation ---

Title   Set Interactive Session Timeout
Rule    xccdf_org.ssgproject.content_rule_accounts_tmout
Result  fail

=================================================================
==85219==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 49 byte(s) in 1 object(s) allocated from:
    #0 0x4a3198 in strdup (/home/jcerny/work/git/openscap/build/utils/oscap+0x4a3198) (BuildId: 329fd48580c8ee52863c16be406cb9d7c3df95db)
    #1 0x7f090491f20c in oscap_strdup /home/jcerny/work/git/openscap/src/common/util.h:312:9
    OpenSCAP#2 0x7f090491e9dd in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:510:26
    OpenSCAP#3 0x7f090491efce in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:574:8
    OpenSCAP#4 0x7f090491f7d3 in ds_sds_dump_component_ref /home/jcerny/work/git/openscap/src/DS/sds.c:601:15
    OpenSCAP#5 0x7f0904917305 in ds_sds_session_register_component_with_dependencies /home/jcerny/work/git/openscap/src/DS/ds_sds_session.c:327:10
    OpenSCAP#6 0x7f0904a0493c in xccdf_session_load_cpe /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:921:8
    OpenSCAP#7 0x7f0904a03dc7 in xccdf_session_load /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:705:14
    OpenSCAP#8 0x53333f in app_evaluate_xccdf /home/jcerny/work/git/openscap/utils/oscap-xccdf.c:641:6
    OpenSCAP#9 0x52fedb in oscap_module_call /home/jcerny/work/git/openscap/utils/oscap-tool.c:295:10
    OpenSCAP#10 0x5307fb in oscap_module_process /home/jcerny/work/git/openscap/utils/oscap-tool.c:389:19
    OpenSCAP#11 0x53cee0 in main /home/jcerny/work/git/openscap/utils/oscap.c:88:15
    OpenSCAP#12 0x7f090390950f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 81daba31ee66dbd63efdc4252a872949d874d136)

SUMMARY: AddressSanitizer: 49 byte(s) leaked in 1 allocation(s).
@jan-cerny jan-cerny mentioned this issue May 9, 2023
Merged
evgenyz added a commit to evgenyz/openscap that referenced this issue Sep 4, 2023
@evgenyz
Add PCRE2 library OpenSCAP#3
0dd73e6 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
evgenyz added a commit to evgenyz/openscap that referenced this issue Sep 4, 2023
@evgenyz
Add PCRE2 library OpenSCAP#3
5a8c2ba 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
evgenyz added a commit to evgenyz/openscap that referenced this issue Sep 5, 2023
@evgenyz
Add PCRE2 library OpenSCAP#3
89c5caa 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
evgenyz added a commit to evgenyz/openscap that referenced this issue Sep 5, 2023
@evgenyz
Add PCRE2 library OpenSCAP#3
f653e07 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
cschuber pushed a commit to cschuber/openscap that referenced this issue Feb 1, 2024
@jan-cerny @cschuber
Plug a memory leak
03f6a09 
When there already exists a value under the given key in the
hash table, oscap_htable_add doesn't put the value to the hash table
and therefore the value isn't freed when the hash table is freed.
The caller of oscap_htable_add needs to check if oscap_htable_add
failed and in this situation is responsible to free the value.

Addressing:

oscap  xccdf eval --profile '(all)' --rule xccdf_org.ssgproject.content_rule_accounts_tmout /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
--- Starting Evaluation ---

Title   Set Interactive Session Timeout
Rule    xccdf_org.ssgproject.content_rule_accounts_tmout
Result  fail

=================================================================
==85219==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 49 byte(s) in 1 object(s) allocated from:
    #0 0x4a3198 in strdup (/home/jcerny/work/git/openscap/build/utils/oscap+0x4a3198) (BuildId: 329fd48580c8ee52863c16be406cb9d7c3df95db)
    #1 0x7f090491f20c in oscap_strdup /home/jcerny/work/git/openscap/src/common/util.h:312:9
    #2 0x7f090491e9dd in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:510:26
    OpenSCAP#3 0x7f090491efce in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:574:8
    OpenSCAP#4 0x7f090491f7d3 in ds_sds_dump_component_ref /home/jcerny/work/git/openscap/src/DS/sds.c:601:15
    OpenSCAP#5 0x7f0904917305 in ds_sds_session_register_component_with_dependencies /home/jcerny/work/git/openscap/src/DS/ds_sds_session.c:327:10
    OpenSCAP#6 0x7f0904a0493c in xccdf_session_load_cpe /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:921:8
    OpenSCAP#7 0x7f0904a03dc7 in xccdf_session_load /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:705:14
    OpenSCAP#8 0x53333f in app_evaluate_xccdf /home/jcerny/work/git/openscap/utils/oscap-xccdf.c:641:6
    OpenSCAP#9 0x52fedb in oscap_module_call /home/jcerny/work/git/openscap/utils/oscap-tool.c:295:10
    OpenSCAP#10 0x5307fb in oscap_module_process /home/jcerny/work/git/openscap/utils/oscap-tool.c:389:19
    OpenSCAP#11 0x53cee0 in main /home/jcerny/work/git/openscap/utils/oscap.c:88:15
    OpenSCAP#12 0x7f090390950f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 81daba31ee66dbd63efdc4252a872949d874d136)

SUMMARY: AddressSanitizer: 49 byte(s) leaked in 1 allocation(s).
cschuber pushed a commit to cschuber/openscap that referenced this issue Feb 1, 2024
@evgenyz @cschuber
Add PCRE2 library OpenSCAP#3
2086325 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
cschuber pushed a commit to cschuber/openscap that referenced this issue Feb 1, 2024
@jan-cerny @cschuber
Plug a memory leak
b2bf9dc 
When there already exists a value under the given key in the
hash table, oscap_htable_add doesn't put the value to the hash table
and therefore the value isn't freed when the hash table is freed.
The caller of oscap_htable_add needs to check if oscap_htable_add
failed and in this situation is responsible to free the value.

Addressing:

oscap  xccdf eval --profile '(all)' --rule xccdf_org.ssgproject.content_rule_accounts_tmout /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
--- Starting Evaluation ---

Title   Set Interactive Session Timeout
Rule    xccdf_org.ssgproject.content_rule_accounts_tmout
Result  fail

=================================================================
==85219==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 49 byte(s) in 1 object(s) allocated from:
    #0 0x4a3198 in strdup (/home/jcerny/work/git/openscap/build/utils/oscap+0x4a3198) (BuildId: 329fd48580c8ee52863c16be406cb9d7c3df95db)
    #1 0x7f090491f20c in oscap_strdup /home/jcerny/work/git/openscap/src/common/util.h:312:9
    #2 0x7f090491e9dd in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:510:26
    OpenSCAP#3 0x7f090491efce in ds_sds_dump_component_ref_as /home/jcerny/work/git/openscap/src/DS/sds.c:574:8
    OpenSCAP#4 0x7f090491f7d3 in ds_sds_dump_component_ref /home/jcerny/work/git/openscap/src/DS/sds.c:601:15
    OpenSCAP#5 0x7f0904917305 in ds_sds_session_register_component_with_dependencies /home/jcerny/work/git/openscap/src/DS/ds_sds_session.c:327:10
    OpenSCAP#6 0x7f0904a0493c in xccdf_session_load_cpe /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:921:8
    OpenSCAP#7 0x7f0904a03dc7 in xccdf_session_load /home/jcerny/work/git/openscap/src/XCCDF/xccdf_session.c:705:14
    OpenSCAP#8 0x53333f in app_evaluate_xccdf /home/jcerny/work/git/openscap/utils/oscap-xccdf.c:641:6
    OpenSCAP#9 0x52fedb in oscap_module_call /home/jcerny/work/git/openscap/utils/oscap-tool.c:295:10
    OpenSCAP#10 0x5307fb in oscap_module_process /home/jcerny/work/git/openscap/utils/oscap-tool.c:389:19
    OpenSCAP#11 0x53cee0 in main /home/jcerny/work/git/openscap/utils/oscap.c:88:15
    OpenSCAP#12 0x7f090390950f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 81daba31ee66dbd63efdc4252a872949d874d136)

SUMMARY: AddressSanitizer: 49 byte(s) leaked in 1 allocation(s).
cschuber pushed a commit to cschuber/openscap that referenced this issue Feb 1, 2024
@evgenyz @cschuber
Add PCRE2 library OpenSCAP#3
e98f516 
Move the oscap_get_substring into the oscap_pcre.c module
and rename it into oscap_pcre_get_substring.

The function imposes implicit dependencies on PCRE/PCRE2 symbols
even for utils.c users that won't use PCRE at all (SCE library).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gregelin @mpreisler @isimluk