# Re: Buggy commit tracked to: "Re: \[PATCH 2/9\] iov\_iter: move rw\_copy\_check\_uvector() into lib/iov\_iter.c"

- From: Al Viro \<viro@zeniv.linux.org.uk\>
- Date: 2020-10-22 20:07:05 
- List: linux-security-module
- Page: https://ratatoskr.run/linux-security-module/2020/10/191049
- Thread: https://ratatoskr.run/linux-arm-kernel/2020/10/191046/t.md

```text
On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote:

> Depending upon the calling conventions, compiler might do truncation in caller or
> in a callee, but it must be done _somewhere_.

Unless I'm misreading AAPCS64,
	"Unlike in the 32-bit AAPCS, named integral values must be narrowed by the callee
	 rather than the caller"
in 6.4.2 means that callee must not _not_ expect the upper 32 bits of %x0..%x7 to contain
anything valid for 32bit arguments and it must zero-extend %w0..%w7 when passing that to
something that expects a 64bit argument.  On inlining it should be the same situation as
storing unsigned int argument into unsigned long local variable and working with that - if

void f(unsigned int w)
{
	unsigned long x = w;
	printf("%lx\n", x);
}

ends up passing %x0 to printf, it's an obvious bug - it must do something like
	uxtw x0, w0
first.

What am I missing here?
```