[Bug 221554] New: hardening/fuzzing project idea: KASAN redzone before skb_shared_info

0 views
Skip to first unread message

bugzill...@kernel.org

unread,
9:42 AM (5 hours ago) 9:42 AM
to kasa...@googlegroups.com
https://bugzilla.kernel.org/show_bug.cgi?id=221554

Bug ID: 221554
Summary: hardening/fuzzing project idea: KASAN redzone before
skb_shared_info
Product: Memory Management
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P3
Component: Sanitizers
Assignee: mm_san...@kernel-bugs.kernel.org
Reporter: ja...@google.com
CC: kasa...@googlegroups.com
Regression: No

The following is not something I'm planning to work on in the near
future, but I think this would be helpful to allow fuzzers to more
easily detect OOB access bugs in the networking subsystem - maybe
someone else is interested in working on this?

As described in https://docs.kernel.org/networking/skbuff.html , in
the networking subsystem, SKB head buffers are stored with a "struct
skb_shared_info" at the end. This means that out-of-bounds accesses to
SKB data in the head buffer can't be detected by KASAN unless they go
far enough out of bounds to go beyond the skb_shared_info.

For debugging/fuzzing, it might be useful to have a KASAN redzone
somewhere between legitimate data in an SKB and skb_shared_info
metadata, accesses into which would cause KASAN splats. Maybe we could
split sk_buff::end into two separate members for "end of tailroom" and
"start of skb_shared_info" so that a redzone can be placed in between?
Or let debug builds store the skb_shared_info in a separate memory
allocation?

(We could also try to go further and KASAN-poison the headroom and
tailroom until they're actually used, but that might require an
annoying amount of refactoring of existing code, so probably not great
as an initial goal.)

dvyukov@ pointed out that there is a related issue
https://bugzilla.kernel.org/show_bug.cgi?id=199055 .

--
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.
Reply all
Reply to author
Forward
0 new messages