Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 11月, 2005 3 次提交
  3. 25 11月, 2005 6 次提交
  5. 24 11月, 2005 2 次提交
  7. 23 11月, 2005 2 次提交
    • D
      [PATCH] Fix hugetlbfs_statfs() reporting of block limits · 74a8a65c
      由 David Gibson 提交于 
      Currently, if a hugetlbfs is mounted without limits (the default), statfs()
will return -1 for max/free/used blocks.  This does not appear to be in
line with normal convention: simple_statfs() and shmem_statfs() both return
0 in similar cases.  Worse, it confuses the translation logic in
put_compat_statfs(), causing it to return -EOVERFLOW on such a mount.

This patch alters hugetlbfs_statfs() to return 0 for max/free/used blocks
on a mount without limits.  Note that we need the test in the patch below,
rather than just using 0 in the sbinfo structure, because the -1 marked in
the free blocks field is used internally to tell the
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      74a8a65c
    • D
      [PATCH] Fix error handling with put_compat_statfs() · 86e07ce7
      由 David Gibson 提交于 
      In fs/compat.c, whenever put_compat_statfs() returns an error, the
containing syscall returns -EFAULT.  This is presumably by analogy with the
non-compat case, where any non-zero code from copy_to_user() should be
translated into an EFAULT.  However, put_compat_statfs() is also return
-EOVERFLOW.  The same applies for put_compat_statfs64().

This bug can be observed with a statfs() on a hugetlbfs directory.
hugetlbfs, when mounted without limits reports available, free and total
blocks as -1 (itself a bug, another patch coming).  statfs() will
mysteriously return EFAULT although it's parameters are perfectly valid
addresses.

This patch causes the compat versions of statfs() and statfs64() to
correctly propogate the return values from put_compat_statfs() and
put_compat_statfs64().
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      86e07ce7
  9. 21 11月, 2005 2 次提交
    • A
      [COMPAT] net: SIOCGIFCONF data corruption · 4909724b
      由 Alexandra Kossovsky 提交于 
      From: Alexandra Kossovsky <Alexandra.Kossovsky@oktetlabs.ru>

From http://bugzilla.kernel.org/show_bug.cgi?id=4746

There is user data corruption when using ioctl(SIOCGIFCONF) in 32-bit
application running amd64 kernel. I do not think that this problem is
exploitable, but any data corruption may lead to security problems.
Following code demonstrates the problem

#include <stdint.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <net/if.h>
#include <sys/ioctl.h>

char buf[256];

main()
{
	int s = socket(AF_INET, SOCK_DGRAM, 0);
	struct ifconf req;
	int i;

	req.ifc_buf = buf;
	req.ifc_len = 41;

	printf("Result %d\n", ioctl(s, SIOCGIFCONF, &req));
	printf("Len %d\n", req.ifc_len);
	for (i = 41; i < 256; i++)
		if (buf[i] != 0)
			printf("Byte %d is corrupted\n", i);
}
	
Steps to reproduce:
Compile the code above into 32-bit elf and run it. You'll get
Result 0
Len 32
Byte 48 is corrupted
Byte 52 is corrupted
Byte 53 is corrupted
Byte 54 is corrupted
Byte 55 is corrupted
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4909724b
    • A
      [PATCH] Remove compat ioctl semaphore · 9e18fcdd
      由 Andi Kleen 提交于 
      Originally for 2.6.16, but the semaphore causes problems for some
people so get rid of it now.

It's not needed anymore because the ioctl hash table is never changed
at run time now.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9e18fcdd
  11. 20 11月, 2005 1 次提交
  13. 19 11月, 2005 4 次提交
  15. 18 11月, 2005 3 次提交
  17. 17 11月, 2005 1 次提交
  19. 16 11月, 2005 3 次提交
  21. 14 11月, 2005 8 次提交
  23. 12 11月, 2005 2 次提交
  25. 11 11月, 2005 3 次提交