netsmb: Fix buggy/racy smb_strdupin()
smb_strdupin() tried to roll a copyin() based strlen to allocate a buffer
and then blindly copyin that size. Of course, a malicious user program
could simultaneously manipulate the buffer, resulting in a non-terminated
string being copied.
Later assumptions in the code rely upon the string being nul-terminated.
Just use copyinstr() and drop the racy sizing.
PR: 222687
Reported by: Meng Xu <meng.xu AT gatech.edu>
Security: possible local DoS
Sponsored by: Dell EMC Isilon
Not clear that this is actually a problem for the kernel -- might
overwrite user's buffers or return garbage to user, but that's their
own damn fault. But it's hard to imagine that negative offset/count
ever makes sense, and I haven't ruled out a problem for the kernel.
nam parameter type from buf * to sockaddr *.
final commit for parameter type changes to protocol user requests
* bump kernel version to 7.99.15 for parameter type changes to pr_{send,connect}
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
To make code in 'external' (etc) still compile, MALLOC_DECLARE() still
has to generate something of type 'struct malloc_type *', with
normal optimisation gcc generates a compile-time 0.
MALLOC_DEFINE() and friends have no effect.
Fix one or two places where the code would no longer compile.
in the vnode. All LK_* flags move from sys/lock.h to sys/vnode.h. Calls
to vlockmgr() in file systems get replaced with VOP_LOCK() or VOP_UNLOCK().
Welcome to 5.99.34.
Discussed on tech-kern.
1.) SMB_CAP_LARGE_FILES advertises support for 64-bit file offsets.
2.) SMB_CAP_LARGE_READX and SMB_CAP_LARGE_WRITEX advertise support for
large reads and writes (larger than 64KB).
The code previously only used SMB_CAP_LARGE_READX and SMB_CAP_LARGE_WRITEX
which is not correct and doesn't work for the Apple Time Capsule which
only supports SMB_CAP_LARGE_FILES. With these changes SMBFS can copy a
5GB to a Time Capsule and read it back without problems.
Thanks a lot to Allen Briggs for pointing out the broke assumptions
and explaining the CIFS spec to me. This fixes PR kern/42175.
there was a danger of smb_iod_recvall() blocking, hence releasing
the kernel lock, new data creeping into the queue, and a wakeup
being missed (well, there's still a race, but since it's theoretical
enough for me to never have encountered it, I'll rather solve it
by periodic wakeups).
christos