<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - nft_set_hash fast lookup broken for 2 byte keys"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1199">1199</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>nft_set_hash fast lookup broken for 2 byte keys
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>nftables
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>x86_64
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>major
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P5
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>kernel
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>pablo@netfilter.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>makovick@gmail.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hi,

after an upgrade of the userspace nftables to v0.8, I found that my port sets
suddenly stopped matching. After some searching, I tracked the issue down to
nft_hash_key and nft_hash_lookup_fast - with v0.8, the kernel started
preferring hashes instead of bitsets.

nft_hash_lookup_fast uses jhash_1word, which always uses the hash initializer
appropriate for keys of length == 4. This means it miscomputes the bucket
location for 2-byte keys and the lookup fails. In addition, lookups for 4-byte
keys will probably fail on big endian machines - the byte-wise jhash used
everywhere else reads the u32s as litle endian.

I tried removing the fast version of the hash lookups, and it indeed fixes the
issue.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>