Right, I had the same reaction in reading this, but actually, his code gets rid of the sockptr_advance stuff entirely and never mutates, so even though my point about attacking those pointers was mis
That doesn't make (much) difference to the code paths that ignore the user-supplied length. OTOH doing the user/kernel check on the base address (not an incremented one) means that the correct copy f
Getting rid of sockptr_advance entirely seems like the right decision here. You still might want to make sure the addition in copy_from_sockptr_offset doesn't overflow, and return -EFAULT if it does
I haven't seen Ido's patch, but it seems clear the issue is that you want to call `sockptr_advance(&arg, sizeof(tmp))`, and adjust sockptr_advance to take a pointer. Slight concern about the whole co
Can you try the patch below? -- sockptr_advance never properly worked. Replace it with _offset variants of copy_from_sockptr and copy_to_sockptr. Fixes: ba423fdaa589 ("net: add a new sockptr_t type")
Hi Christoph, Something along this path seems to have broken with this patch. An invocation of `iptables -A INPUT -m length --length 1360 -j DROP` now fails, with nf_setsockopt->do_replace->translate
Pass a sockptr_t to prepare for set_fs-less handling of the kernel pointer from bpf-cgroup. Signed-off-by: Christoph Hellwig <hch@xxxxxx> -- include/linux/netfilter.h | 6 ++++-- net/bridge/netfilter/