Hi, Apologies for my mistake in these threads. I think the title should read 'out of bounds read'. I noticed there may be a floating point error or another miscellaneous approximation error when calculating the mask for raw payload expressions. It is somewhat related to this thread. using nft -d all (debug all); I found: inet filter output 5 4 [ payload load 2b @ inner header + 6 => reg 1 ] [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] After careful consideration, I realised that here; '2b' indicates two bytes, not two bits. I suggest it should read '2 Bytes'. Additionally, the "+ 6" section should really read as "+ 6 Bytes". "2B" or "6B" may get misread as 28, or 68; if the user makes a poor choice in font. Poor choice in font is not my concern, particularly; but fault-tolerant design is always nice. Anyhow, with the alterations to expression; I can then match it (2 bytes, offset of 6 bytes) to the 'mangled' input of @ih,48,16 > [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] Assuming that the mask is stored in a 32-bit integer field, the length of the string is fine. Otherwise, the mask of "0x0000c0ff" equates to 49,407 bits. Since raw payload expression includes the starting position in payload expressions; it is really 49,408 bits to match. Via empirical calculation, the closest base 2 logarithm I can find for 49,407 (bits) is approximately ~15.5924570373. If the mask is intended to cover 16 bits; should it not equate to 65,535 bits; or "0x0000ffff". Though, the intent was not to read and set the same value; rather, it was to redact 6 bits of data. Considering the intent of my input statement (@ih,58,6); I think the mask should be ((2^16) - (2^6)); or 65,472 in decimal; or 0xfff9 in hexadecimal. This leaves us with an output statement of (little endian mask, as it seems is the case): @ih,48,16 set @ih,48,16 & 0xfff9 The statement: > [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] Should then read: > [ bitwise reg 1 = ( reg 1 & 0x0000fff9 ) ^ 0x00000000 ] sunny
