Hi, Replying to the bot's two questions:
1. How the issue was discovered Manual code inspection, combined with a static-analysis scan of net/ that flagged the unchecked skb_mac_header() dereference in ebt_802_3_mt(). After the scan report I read the surrounding code by hand (ebtables.c ebt_do_table()/ebt_basic_match(), the bridge RX path, and eth_type_trans()) to confirm that nothing between the RX entry and this match guarantees more than ETH_HLEN (14) linear bytes past the mac header is available, and that no pskb_may_pull() runs in between. 2. Whether the issue was actually triggered Not triggered. This is theoretical, found by code inspection only. There is no runtime report, stack trace, or crash log on my side. The reasoning chain is: - ebt_802_3_mt() casts skb_mac_header(skb) directly to struct ebt_802_3_hdr * and dereferences fields up to machdr + 22 (the ni branch of the LLC union). - The ebtables core never calls pskb_may_pull() before running the per-rule matches. - So an 802.3 frame (length field below 1536) whose skb carries nothing past the 14-byte Ethernet header reaches the match with machdr + 22 pointing into tailroom. The fix in the patch deliberately chooses a conservative predicate: it drops the packet whenever fewer than (ETH_HLEN + ebt 802.3 header size) bytes are linear, which can also drop frames whose LLC union is technically still inside the linear area but shorter than that. In practice the minimum Ethernet frame is 60 bytes, so skb_headlen under 37 only occurs on truncated or malformed frames, where dropping is the reasonable response. Fixing a potential OOB read is not worth adding a second rule for. If a runtime reproducer is needed, I can build one with a raw socket and a veth pair, but I think the code-level analysis is conclusive. Guo Zihao
