fix: probably UB (left shift of neg. val) in ip_tree

[airween]

what

This PR fixes a possible undefined behavior (UB) in IP TREE during the execution of @ipMatch.

why

There is a bug report, received in email from @fumfel and his team. Also they provided this fix.

references

The original report:

Root Cause
----------

The SHIFT_LEFT_MASK(x) macro computes (-1) << (x) to create a bitmask
with x zero bits on the right. On two's complement architectures with
arithmetic shifts, this produces the expected result. However, it is
formally undefined behavior per the C and C++ standards. Aggressive
compiler optimizations (such as -fstrict-overflow) could produce
unexpected results.

The bug triggers when processing IP addresses for @ipMatch with certain
netmask values. Input "\0::1" (null byte + IPv6 loopback notation)
reaches CPTFindElement where ip_bitmask % 8 == 0, producing
(-1) << 8.

other notes

The bug can only be exploited if the source code was built with different flags, like -fsanitize=address,undefined -fno-sanitize-recover=all and the admin puts a \0 byte into operator's argument on some way.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR removes a case of undefined behavior in the IP tree bitmask logic used by the @ipMatch operator by avoiding left-shifting a negative signed value.

Changes:

• Update SHIFT_LEFT_MASK(x) to build the mask via an unsigned all-ones value (~0U) before shifting, eliminating UB from (-1) << x.
• Keep the rest of the IP tree matching logic unchanged while making sanitizer/optimization behavior predictable.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.