gcoap: fix underflow when correcting ETag from cache

[miri64]

Contribution description

Fixes an underflow error when getting a new ETag from cache, by returning early.

Testing procedure

I repeated the testing procedures from #17801 (comment) (attention, the expected input for examples/gcoap changed slightly in the last year and a half)

diff --git a/aiocoap/cli/fileserver.py b/aiocoap/cli/fileserver.py
index 6af2b84..f5a9e71 100644
--- a/aiocoap/cli/fileserver.py
+++ b/aiocoap/cli/fileserver.py
@@ -154,6 +154,7 @@ class FileServer(Resource, aiocoap.interfaces.ObservableResource):
             elif S_ISREG(st.st_mode):
                 response = await self.render_get_file(request, path)
 
+        response.opt.max_age = 10
         response.opt.etag = etag
         return response
 

)

$ sudo ./dist/tool/tapsetup/tapsetup
$ PORT=tap1 USEMODULE="gcoap_forward_proxy nanocoap_cache" make -C examples/gcoap -j flash term
...
> ifconfig
ifconfig
Iface  6  HWaddr: DA:27:1D:A8:64:24 
          L2-PDU:1500  MTU:1500  HL:64  Source address length: 6
          Link type: wired
          inet6 addr: fe80::d827:1dff:fea8:6424  scope: link  VAL
          inet6 group: ff02::1
          inet6 group: ff02::1:ffa8:6424

> 
[second terminal in aiocoap repo]
$ ip addr show dev tapbr0 scope link
5: tapbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether de:1a:a8:09:45:b3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::dc1a:a8ff:fe09:45b3/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
$ mkdir -p test
$ echo "foobar" > test/a.txt
$ ./aiocoap-fileserver --bind "[$(ip addr show dev tapbr0 scope link | grep -o 'inet6 [0-9a-f:]\+' | sed 's/inet6 //')%tapbr0]" test/
...
[third terminal]
$ make -C examples/gcoap term
All up, running the shell now
> coap proxy set [fe80::d827:1dff:fea8:6424]:5683
coap proxy set [fe80::d827:1dff:fea8:6424]:5683
> coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
gcoap_cli: sending msg ID 17604, 63 bytes
> --- blockwise start ---
gcoap: response Success, code 2.05, 7 bytes
foobar

--- blockwise complete ---
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
gcoap_cli: sending msg ID 17605, 63 bytes
--- blockwise start ---
gcoap: response Success, code 2.05, 7 bytes
foobar

--- blockwise complete ---

[wait >10 sec]

> coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
gcoap_cli: sending msg ID 17606, 63 bytes
> --- blockwise start ---
gcoap: response Success, code 2.05, 7 bytes
foobar

--- blockwise complete ---
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
coap get [fe80::dc1a:a8ff:fe09:45b3]:5683 /a.txt
gcoap_cli: sending msg ID 17607, 63 bytes
--- blockwise start ---
gcoap: response Success, code 2.05, 7 bytes
foobar

--- blockwise complete ---
> ^C
native: exiting

Sniffing on tapbr0 should show something like.

Issues/PRs references

Reported off-band.

[riot-ci]

Murdock results

✔️ PASSED

8d1cb1b gcoap: fix underflow when correcting ETag from cache

Success	Failures	Total	Runtime
7937	0	7937	14m:31s

Artifacts

• Documentation preview

[chrysn]

I find it weird that we allow responses with invalid ETag values into our caches in the first place, or that opt_get_opaque can even return values outside the buffer, but that'd probably be out of scope for the bug fix here.

Looks good to me.

Note for other reviewers: The example given in the report is not showing errant behavior, it merely demonstrates that things work fine before and after when given valid inputs.

[chrysn]

That's already false from an earlier check, but it doesn't hurt to be explicit either (the compiler will remove it anyway).

[chrysn]

bors merge

[bors]

Build failed:

• static-tests

[miri64]

Build failed:

* static-tests

Seems completely unrelated. :-(

[miri64]

bors merge

[bors]

Build failed:

• Murdock

[miri64]

bors merge

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Murdock
• static-tests
• tools-build-success