Rule with double check ignore with 802.1Q packet

Hello,

I found a weird behavior with NF tables. I am trying to filter specific packets and I cannot understand what is going on in the following case. It looks like a bug, but I do not know NFT very well so I prefer to ask first.

I am using 2 virtual interfaces veth0 and veth1 on Linux:
Linux sopvubu22-214d 6.8.0-64-generic #67~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Jun 24 15:19:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Interfaces were created with:
ip link add veth0 type veth peer name veth1


NFT were configured with the following script:
---
#!/usr/sbin/nft -f

flush ruleset

# INPUT Filtering
table netdev tb_in {
    chain ch_in {
        type filter hook ingress device veth1 priority 100;
        nftrace set 1
        ether saddr AA:BB:CC:DD:00:38   log prefix "--test 1-- "
        ip saddr 192.168.140.56         log prefix "--test 2-- "
        ether saddr AA:BB:CC:DD:00:38 ip saddr 192.168.140.56 log prefix "--tests 1&2 -- "
        ip saddr 192.168.140.56 ether saddr AA:BB:CC:DD:00:38  log prefix "--tests 2&1 -- "
    }
}
---
Then I send this specific packet:
echo AA BB CC DD 00 50 AA BB CC DD 00 38 81 00 28 48 08 00 45 00 00 1C 00 01 00 00 40 11 E0 F6 C0 A8 8C 38 C0 A8 8C 50 1D 89 1D 83 00 08 2A F8 | xxd -r -p | socat - INTERFACE:veth0

And I get the following log:
trace id 5235f40e netdev tb_in ch_in packet: iif "veth1" ether saddr aa:bb:cc:dd:00:38 ether daddr aa:bb:cc:dd:00:50 vlan pcp 1 vlan dei 0 vlan id 2120 ip saddr 192.168.140.56 ip daddr 192.168.140.80 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 1 ip protocol udp ip length 28 udp sport 7561 udp dport 7555 udp length 8
trace id 5235f40e netdev tb_in ch_in rule meta nftrace set 1 (verdict continue)
trace id 5235f40e netdev tb_in ch_in rule ether saddr aa:bb:cc:dd:00:38 log prefix "--test 1-- " (verdict continue)
trace id 5235f40e netdev tb_in ch_in rule ip saddr 192.168.140.56 log prefix "--test 2-- " (verdict continue)
trace id 5235f40e netdev tb_in ch_in rule ip saddr 192.168.140.56 ether saddr aa:bb:cc:dd:00:38 log prefix "--tests 2&1 -- " (verdict continue)
trace id 5235f40e netdev tb_in ch_in policy accept

What is very strange is that the "test 1 & 2" is failing, despite being exactly identical, apart the order, to other tests. I get the same log with 'dmesg'.

The packet sent can be decomposed in (ether + vlan + ip + udp) headers but no data. And if I remove the vlan part (81 00 28 48), it works.

Is it a bug or do I miss something ? Maybe it has been corrected in a newer kernel version?

Thanks for your help,
Antoine