Rousette crash when request a list with two keys

[mattiaswal]

According to 3.5.2 in ietf-restconf this is how you should send multiple keys

admin@R1:~$ curl -u admin:admin -H "Accept: application/yang-data+json" -kX GET "https://localhost/restconf/data/ietf-routing:routing/control-plane-protocols/control-plane-protocol=ospfv2,default"



<title>Error</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>


An error occurred.
Sorry, the page you are looking for is currently unavailable.


admin@R1:~$ 

Sep 26 06:23:11 R1 rousette[4558]: [2024-09-26 06:23:11.180] [rousette] [info] [::1]:49482: GET /restconf/data/ietf-routing:routing/control-plane-protocols/control-plane-protocol=ospfv2,default 
Sep 26 06:23:11 R1 kernel: rousette[4565]: segfault at 8 ip 00007f3221b98ff8 sp 00007f3220300b10 error 4 in libyang.so.3.4.2[7f3221adb000+d2000] likely on CPU 0 (core 0, socket 0)
Sep 26 06:23:11 R1 kernel: Code: 8b 16 83 3c 82 03 74 d2 48 8b 04 24 48 8b b4 24 80 00 00 00 48 8b 78 40 e8 35 33 f4 ff 48 8b b4 24 90 00 00 00 48 85 f6 74 0c <49> 8b 45 08 48 8b 38 e8 9c a9 f4 ff 41 83 ff 0b 0f 84 9a 04 00 00
Sep 26 06:23:11 R1 nginx: 2024/09/26 06:23:11 [error] 3793#0: *250 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: _, request: "GET /restconf/data/ietf-routing:routing/control-plane-protocols/control-plane-protocol=ospfv2,default HTTP/1.1", upstream: "grpc://[::1]:10080", host: "localhost"
Sep 26 06:23:11 R1 nginx: ::1 - admin [26/Sep/2024:06:23:11 +0000] "GET /restconf/data/ietf-routing:routing/control-plane-protocols/control-plane-protocol=ospfv2,default HTTP/1.1" 502 318 "-" "curl/8.9.0"

[peckato1]

This is weird, we definitely test for querying multiple keys and I was not able to reproduce this. Is it possible for you to send us a stacktrace, or get more details?

[mattiaswal]

This is weird, we definitely test for querying multiple keys and I was not able to reproduce this. Is it possible for you to send us a stacktrace, or get more details?

I get this in a virtual x86_64 machine (stripped binaries) , I will recompile and not strip target binaries

[mattiaswal]

Looks like the bug is in libyang:

(gdb) bt
#0  eval_name_test_with_predicate (options=, set=, all_desc=, axis=, tok_idx=, 
    exp=) at ../src/xpath.c:8276
#1  eval_relative_location_path (exp=exp@entry=0x7f83e401b470, tok_idx=tok_idx@entry=0x7f83e9626cd4, all_desc=, set=0x7f83e9626da0, 
    options=1) at ../src/xpath.c:8446
#2  0x00007f83eaebfbc7 in eval_path_expr (options=0, set=0x7f83e9626da0, tok_idx=0x7f83e9626cd4, exp=0x7f83e401b470) at ../src/xpath.c:8998
#3  0x00007f83eaec10c9 in lyxp_eval (ctx=0x55a0c46a0320, exp=0x7f83e401b470, cur_mod=cur_mod@entry=0x0, format=format@entry=LY_VALUE_JSON, 
    prefix_data=prefix_data@entry=0x0, cur_node=cur_node@entry=0x7f83e401e9b0, ctx_node=0x7f83e401e9b0, tree=, vars=0x0, set=0x7f83e9626da0, 
    options=1) at ../src/xpath.c:9736
#4  0x00007f83eae1b8f6 in lyd_eval_xpath4 (ctx_node=ctx_node@entry=0x7f83e401e9b0, tree=tree@entry=0x7f83e401e9b0, cur_mod=cur_mod@entry=0x0, 
    xpath=xpath@entry=0x7f83e401b9d0 "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='ospfv2'][name='default']", 
    format=format@entry=LY_VALUE_JSON, prefix_data=prefix_data@entry=0x0, vars=0x0, ret_type=0x0, node_set=0x7f83e9626fd8, string=0x0, number=0x0, 
    boolean=0x0) at ../src/tree_data.c:3363
#5  0x00007f83eae1be9e in lyd_find_xpath3 (ctx_node=ctx_node@entry=0x7f83e401e9b0, tree=tree@entry=0x7f83e401e9b0, 
    xpath=xpath@entry=0x7f83e401b9d0 "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='ospfv2'][name='default']", 
    format=format@entry=LY_VALUE_JSON, prefix_data=prefix_data@entry=0x0, vars=vars@entry=0x0, set=0x7f83e9626fd8) at ../src/tree_data.c:3322
#6  0x00007f83eae1bf62 in lyd_find_xpath (ctx_node=ctx_node@entry=0x7f83e401e9b0, 
    xpath=xpath@entry=0x7f83e401b9d0 "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='ospfv2'][name='default']", 
    set=set@entry=0x7f83e9626fd8) at ../src/tree_data.c:3303
#7  0x00007f83ead4dfca in sr_lyd_find_xpath (tree=0x7f83e401e9b0, 
    xpath=0x7f83e401b9d0 "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='ospfv2'][name='default']", set=0x7f83e9626fd8)
    at src/ly_wrap.c:1004
#8  0x00007f83ead5a818 in sr_modinfo_get_filter (mod_info=mod_info@entry=0x7f83e9627010, 
    xpath=xpath@entry=0x7f83e401b9d0 "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='ospfv2'][name='default']", 
    session=session@entry=0x7f83e4019220, result=result@entry=0x7f83e9626fd8) at src/modinfo.c:3245
#9  0x00007f83ead3917e in sr_get_data (session=0x7f83e4019220, xpath=, max_depth=0, timeout_ms=, opts=, 
    data=0x7f83e96270b8) at src/sysrepo.c:3146
#10 0x00007f83eb48ad48 in sysrepo::Session::getData (this=this@entry=0x7f83e9627300, path=..., maxDepth=maxDepth@entry=0, opts=, timeout=...)
    at src/Session.cpp:198
#11 0x000055a0c45beb11 in operator() (__closure=0x7f83e40191a0, req=..., 
    res=...) at src/restconf/Server.cpp:976

May of course be the input to libyang, but i report it there and see what he says.

[mattiaswal]

It works from sysrepo, so I wonder whats wrong here.

admin@ix-00-00-00:~$ sysrepocfg -X -fjson -x "/ietf-routing:routing/control-plane-protocols/control-plane-protocol[type='infix-routing:ospfv2' and name='default']"
{
  "ietf-routing:routing": {
    "control-plane-protocols": {
      "control-plane-protocol": [
        {
          "type": "infix-routing:ospfv2",
          "name": "default",
          "ietf-ospf:ospf": {
            "areas": {
              "area": [
                {
                  "area-id": "0.0.0.0",
                  "interfaces": {
                    "interface": [
                      {
                        "name": "e1",
                        "enabled": true
                      }
                    ]
                  }
                }
              ]
            }
          }
        }
      ]
    }
  }
}

[mattiaswal]

I realized i was missing the infix-routing prefix, when i tried this with RESTCONF:

admin@ix-00-00-00:~$ curl -u admin:admin -H "Accept: application/yang-data+json" -kX GET "https://localhost/restconf/data/ietf-routing:routing/control-plane-protocols/control-plane-protocol=infix-routing:ospfv2,default"
{
  "ietf-restconf:errors": {
    "error": [
      {
        "error-type": "application",
        "error-tag": "operation-failed",
        "error-message": "Syntax error"
      }
    ]
  }
}

[mattiaswal]

My last comment i think is a bug in Rousette, what do you say @peckato1

[peckato1]

My last comment i think is a bug in Rousette, what do you say @peckato1

Yes, I will look into it. Thanks for reporting this!

[peckato1]

So, the segfault was indeed in libyang and is reported in sysrepo/sysrepo#3425 and fixed in CESNET/libyang@9805f21.

I will add support for specifying prefixes in list keys soon.