[lts 9.2-rt] tap: add missing verification for short frame

[jallisonciq]

kernel-selftest-rt-baseline-9.2.log
kernel-selftest-rt-patched-9.2.log
kernel_build_log_9_2_rt.log

$ uname -a
Linux r92rtlts 5.14.0-ciqlts9_2-rt+ #1 SMP PREEMPT_RT Wed Feb 12 00:30:33 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

jira VULN-9073
cve CVE-2024-41090
commit-author Si-Wei Liu [email protected]
commit ed7f2af

The cited commit missed to check against the validity of the frame length in the tap_get_user_xdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tap_get_user_xdp()-->skb_set_network_header() may assume the size is more than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tap_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted.

This is to drop any frame shorter than the Ethernet header size just like how tap_get_user() does.

CVE: CVE-2024-41090
Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: 0efac27 ("tap: accept an array of XDP buffs through sendmsg()")
Cc: [email protected]
Signed-off-by: Si-Wei Liu [email protected]
Signed-off-by: Dongli Zhang [email protected]
Reviewed-by: Willem de Bruijn [email protected]
Reviewed-by: Paolo Abeni [email protected]
Reviewed-by: Jason Wang [email protected]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski [email protected]
(cherry picked from commit ed7f2af)

[gvrose8192]

In the build log https://github.com/user-attachments/files/18774612/kernel_build_log_9_2_rt.log there should be some indication that the kABI check was skipped because this is an RT kernel. I'm not seeing that so I am not sure what tools you're using for this build. Are you sure that the VM you're running this on is using the correct kernel-tools branch? I hate to be a nit on this but an indication that the tools were smart enough to recognize and skip the kABI check for this kernel is ensuring that the latest kernel-tools are being used.

[jallisonciq]

In the build log https://github.com/user-attachments/files/18774612/kernel_build_log_9_2_rt.log there should be some indication that the kABI check was skipped because this is an RT kernel. I'm not seeing that so I am not sure what tools you're using for this build. Are you sure that the VM you're running this on is using the correct kernel-tools branch? I hate to be a nit on this but an indication that the tools were smart enough to recognize and skip the kABI check for this kernel is ensuring that the latest kernel-tools are being used.

I'm using a custom script, one I modified from ./kernel_build.sh - it exits before doing the "sudo make install" so I run this by hand. The original had problems - I had to add the code:

elif [ -f configs/kernel-rt-${VERSION}-${ARCH}.config ]; then
    cp -v configs/kernel-rt-${VERSION}-${ARCH}.config .config

to ensure I was getting the rt-config (that wasn't present originally).

tl;dr, I skipped the:

echo "Checking kABI"

../kernel-dist-git/SOURCES/check-kabi -k ../kernel-dist-git/SOURCES/Module.kabi_x86_64 -s Module.symvers || echo "kABI failed"

KABI_CHECK=$(../kernel-dist-git/SOURCES/check-kabi -k ../kernel-dist-git/SOURCES/Module.kabi_${ARCH} -s Module.symvers)
if [ $? -ne 0 ]; then
echo "Error: kABI check failed"
exit 1
fi

code by hand as I knew it wasn't needed for an rt kernel.

[jallisonciq]

I'm using a custom script, one I modified from ./kernel_build.sh - it exits before doing the "sudo make install" so I run this by hand. The original had problems - I had to add the code:

I was planning to go back and try and update the upstream code to ensure it works on the rt kernels once I'd gotten all the changes for this CVE in place.

[PlaidCat]

Thanks for correcting the test stuff.

[gvrose8192]

Thanks!

[bmastbergen]

🥌