ffs_setextattr() is used to set a named attribute to an ffs vfs. the problem is that it takes some user controlled data, the interesting ones are: ap->a_name (arbitrary user string, not checked), and ip->i_ea_len (unsigned int), which also isn't checked. the function uses ip->i_ea_len + ealength (which is 7 + strlen(ap->a_name)) for allocating a buffer, after that user-controlled data are copied to the buffer using ip->i_ea_len. providing an INT_MAX ip->i_ea_len + 2^32 + 2 long string will cause an integer overflow, and the buffer in the heap will be 1 byte, but the bcopy will copy 2^32 bytes to the buffer. this should be reachable from an unprivileged user (since extattr_check_cred() doesn't require root if the attrnamespace is set to EXTATTR_NAMESPACE_USER), but seems to be difficult to exploit, since you'd need 4GBs of ram (for the long string) just to perform the 2^32 heap overflow, an exploitable overflow will probably take even more memory.
The attribute name length is checked by callers of the VOP, or is not user-controlled to begin with. Callers of extattr_set_vp(), for example, will provide a string of length at most EXTATTR_MAXNAMELEN == NAME_MAX. We should perhaps assert this limit in ffs_setextattr(). ip->i_ea_len is not directly user-controlled, it is the size of the extattrs for the inode represented by ip. The space reserved for extattrs is limited to two blocks and ffs_setextattr() checks this. I may well be missing something - do you have a test case to demonstrate the problem?
unfortunately I haven’t, from my static analysis I haven’t noticed the name length check, so I probably missed something. anyway since you’re here, I’ve reported another bug a week ago, but I haven’t received any news about it, could you provide me some infos about it? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254737 that’s it.
(In reply to Tommaso from comment #2) Bjoern is working on it. In the meantime I will close this report, seems to be a false positive.