CVE-2023-54181

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix issue in verifying allow_ptr_leaks

After we converted the capabilities of our networking-bpf program from cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program failed to start. Because it failed the bpf verifier, and the error log is "R3 pointer comparison prohibited".

A simple reproducer as follows,

SEC("cls-ingress") int ingress(struct __sk_buff *skb) { struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr);

if ((long)(iph + 1) > (long)skb->data_end)
	return TC_ACT_STOLEN;
return TC_ACT_OK;

}

Per discussion with Yonghong and Alexei [1], comparison of two packet pointers is not a pointer leak. This patch fixes it.

Our local kernel is 6.1.y and we expect this fix to be backported to 6.1.y, so stable is CCed.

[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/

A verifier correctness issue in the Linux kernel BPF subsystem can prevent otherwise valid networking BPF programs from loading when capabilities are reduced from CAP_SYS_ADMIN to CAP_BPF plus CAP_NET_ADMIN. The verifier reports R3 pointer comparison prohibited for a common bounds check pattern that compares two packet derived pointers such as iph plus 1 against skb data_end. The verifier logic treated any pointer comparison as a potential pointer leak and rejected it. However comparing two packet pointers does not expose kernel addresses and is a standard safe pattern used to validate packet bounds before dereferencing headers. The patch adjusts check_cond_jmp_op to validate operands in the correct order and to explicitly allow comparisons where both operands are packet pointers while still prohibiting pointer comparisons that could leak sensitive addresses.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.