Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux
Jes Sorensen wrote: I am pleased to announce the availability of mdadm version 4.0 It is available at the usual places: http://www.kernel.org/pub/linux/utils/raid/mdadm/ and via git at git://git.kernel.org/pub/scm/utils/mdadm/mdadm.git http://git.kernel.org/cgit/utils/mdadm/ The update in major version number primarily indicates this is a release by it's new maintainer. In addition it contains a large number of fixes in particular for IMSM RAID and clustered RAID support. In addition this release includes support for IMSM 4k sector drives, failfast and better documentation for journaled RAID. Thank you for the new release. Unfortunately I get 9 failures running the test suite: tests/00raid1... FAILED tests/07autoassemble... FAILED tests/07changelevels... FAILED tests/07revert-grow...FAILED tests/07revert-inplace... FAILED tests/07testreshape5... FAILED tests/10ddf-fail-twice... FAILED tests/20raid5journal... FAILED tests/10ddf-incremental-wrong-order... FAILED The procedure I used was make sudo ./test --keep-going --logdir=test-logs --save-logs I'll also note that there is an irritating message when a test fails: cp: cannot stat '/var/tmp/log': No such file or directory This can be fixed easily enough with: sed -i 's# if.* == "1"#& -a -e $targetdir/log#' test I don't know if this mailing list is the right place to report bugs or not. I do not want to spam the list with the logs but they are available at: http://anduin.linuxfromscratch.org/~bdubbs/mdadm-logs/ -- Bruce Dubbs linuxfromscratch.org
Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux
Jes Sorensen wrote: I am pleased to announce the availability of mdadm version 4.0 It is available at the usual places: http://www.kernel.org/pub/linux/utils/raid/mdadm/ and via git at git://git.kernel.org/pub/scm/utils/mdadm/mdadm.git http://git.kernel.org/cgit/utils/mdadm/ The update in major version number primarily indicates this is a release by it's new maintainer. In addition it contains a large number of fixes in particular for IMSM RAID and clustered RAID support. In addition this release includes support for IMSM 4k sector drives, failfast and better documentation for journaled RAID. Thank you for the new release. Unfortunately I get 9 failures running the test suite: tests/00raid1... FAILED tests/07autoassemble... FAILED tests/07changelevels... FAILED tests/07revert-grow...FAILED tests/07revert-inplace... FAILED tests/07testreshape5... FAILED tests/10ddf-fail-twice... FAILED tests/20raid5journal... FAILED tests/10ddf-incremental-wrong-order... FAILED The procedure I used was make sudo ./test --keep-going --logdir=test-logs --save-logs I'll also note that there is an irritating message when a test fails: cp: cannot stat '/var/tmp/log': No such file or directory This can be fixed easily enough with: sed -i 's# if.* == "1"#& -a -e $targetdir/log#' test I don't know if this mailing list is the right place to report bugs or not. I do not want to spam the list with the logs but they are available at: http://anduin.linuxfromscratch.org/~bdubbs/mdadm-logs/ -- Bruce Dubbs linuxfromscratch.org
Re: [ANNOUNCE] util-linux v2.25-rc1
Karel Zak wrote: The util-linux release v2.25 is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.25 Feedback and bug reports, as always, are welcomed. In an LFS build environment, the configure, make, and make check are all clean. It is especially nice the way you tell us why some tests are not run (mostly not root permissions). In prior releases, the last/ipv6 and last/last tests did not pass in the LFS environment, but they now do pass. It would be nice if we could set the adjtime path in configure. Right now we do: sed -i -e 's@etc/adjtime@var/lib/hwclock/adjtime@g' \ $(grep -rl '/etc/adjtime' .) -- Bruce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux v2.25-rc1
Karel Zak wrote: The util-linux release v2.25 is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.25 Feedback and bug reports, as always, are welcomed. In an LFS build environment, the configure, make, and make check are all clean. It is especially nice the way you tell us why some tests are not run (mostly not root permissions). In prior releases, the last/ipv6 and last/last tests did not pass in the LFS environment, but they now do pass. It would be nice if we could set the adjtime path in configure. Right now we do: sed -i -e 's@etc/adjtime@var/lib/hwclock/adjtime@g' \ $(grep -rl '/etc/adjtime' .) -- Bruce -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] kmod 10
Jan Engelhardt wrote: On Thursday 2012-09-06 21:37, Lucas De Marchi wrote: kmod 10 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign make check fails here with glibc-2.15, gcc-4.7, x86_64, due to what seems to be duplicated symbols(?) On my LFS system, glibc-2.16, gcc-4.7.1, x86_64, I do not see these errors: ./configure --prefix=/usr --bindir=/bin --libdir=/lib \ --sysconfdir=/etc --with-xz --with-zlib make make check == All 9 tests passed == What is interesting is that if I run the checks again: make check I get: TESTSUITE: running modprobe_softdep_loop, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-modprobe/softdep-loop is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'modprobe_softdep_loop' [16407] exited with return code 1 TESTSUITE: ERR: FAILED: modprobe_softdep_loop FAIL: testsuite/test-modprobe TESTSUITE: running test_insert, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-init/ is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'test_insert' [16373] exited with return code 1 TESTSUITE: ERR: FAILED: test_insert FAIL: testsuite/test-init == 2 of 9 tests failed Please report to linux-modu...@vger.kernel.org == 'make rootfs' does not do anything but make distclean && configure && make && make check is clean for me. -- Bruce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] kmod 10
Jan Engelhardt wrote: On Thursday 2012-09-06 21:37, Lucas De Marchi wrote: kmod 10 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign make check fails here with glibc-2.15, gcc-4.7, x86_64, due to what seems to be duplicated symbols(?) On my LFS system, glibc-2.16, gcc-4.7.1, x86_64, I do not see these errors: ./configure --prefix=/usr --bindir=/bin --libdir=/lib \ --sysconfdir=/etc --with-xz --with-zlib make make check == All 9 tests passed == What is interesting is that if I run the checks again: make check I get: TESTSUITE: running modprobe_softdep_loop, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-modprobe/softdep-loop is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'modprobe_softdep_loop' [16407] exited with return code 1 TESTSUITE: ERR: FAILED: modprobe_softdep_loop FAIL: testsuite/test-modprobe TESTSUITE: running test_insert, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-init/ is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'test_insert' [16373] exited with return code 1 TESTSUITE: ERR: FAILED: test_insert FAIL: testsuite/test-init == 2 of 9 tests failed Please report to linux-modu...@vger.kernel.org == 'make rootfs' does not do anything but make distclean configure make make check is clean for me. -- Bruce -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add additional error check to mm/mincore.c
I some circumstances, mincore can succeed when it shouldn't.
Example:
Two files are mmapped to a process and they are adjacent in memory.
If mincore is run with a requested length that is too large, the
function does not differentiate between the different file pointers
within the different vma structures and inappropriately returns success.
The attached patch, against 2.6.20.3, fixes this behavior.
This behavior was found when running the Linux Test Project's mincore01
on an IA32 system. Test 3 "unexpectedly" succeeds.
-- Bruce
--- mm/mincore.c.old2007-03-24 19:55:01.0 -0500
+++ mm/mincore.c2007-03-24 20:13:43.0 -0500
@@ -43,7 +43,8 @@
* all the arguments, we hold the mmap semaphore: we should
* just return the amount of info we're asked for.
*/
-static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long
pages)
+static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long
pages,
+struct file** file_struct)
{
unsigned long i, nr, pgoff;
struct vm_area_struct *vma = find_vma(current->mm, addr);
@@ -64,7 +65,19 @@
* this is what we've traditionally done, so we'll just
* continue doing it.
*/
- if (!vma->vm_file)
+
+/*
+ * Initialize file pointer to the value in the first vma structure
+ */
+
+if ( *file_struct == NULL && vma->vm_file )
+*file_struct = vma->vm_file;
+
+/*
+ * Return an error if the is no file mapped of the file is different
+ */
+
+ if (!vma->vm_file || vma->vm_file != *file_struct)
return -ENOMEM;
/*
@@ -115,6 +128,7 @@
long retval;
unsigned long pages;
unsigned char *tmp;
+static struct file* file = NULL;
/* Check the start address: needs to be page-aligned.. */
if (start & ~PAGE_CACHE_MASK)
@@ -142,7 +156,7 @@
* the temporary buffer size.
*/
down_read(>mm->mmap_sem);
- retval = do_mincore(start, tmp, min(pages, PAGE_SIZE));
+ retval = do_mincore(start, tmp, min(pages, PAGE_SIZE), );
up_read(>mm->mmap_sem);
if (retval <= 0)
[PATCH] Add additional error check to mm/mincore.c
I some circumstances, mincore can succeed when it shouldn't.
Example:
Two files are mmapped to a process and they are adjacent in memory.
If mincore is run with a requested length that is too large, the
function does not differentiate between the different file pointers
within the different vma structures and inappropriately returns success.
The attached patch, against 2.6.20.3, fixes this behavior.
This behavior was found when running the Linux Test Project's mincore01
on an IA32 system. Test 3 unexpectedly succeeds.
-- Bruce
--- mm/mincore.c.old2007-03-24 19:55:01.0 -0500
+++ mm/mincore.c2007-03-24 20:13:43.0 -0500
@@ -43,7 +43,8 @@
* all the arguments, we hold the mmap semaphore: we should
* just return the amount of info we're asked for.
*/
-static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long
pages)
+static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long
pages,
+struct file** file_struct)
{
unsigned long i, nr, pgoff;
struct vm_area_struct *vma = find_vma(current-mm, addr);
@@ -64,7 +65,19 @@
* this is what we've traditionally done, so we'll just
* continue doing it.
*/
- if (!vma-vm_file)
+
+/*
+ * Initialize file pointer to the value in the first vma structure
+ */
+
+if ( *file_struct == NULL vma-vm_file )
+*file_struct = vma-vm_file;
+
+/*
+ * Return an error if the is no file mapped of the file is different
+ */
+
+ if (!vma-vm_file || vma-vm_file != *file_struct)
return -ENOMEM;
/*
@@ -115,6 +128,7 @@
long retval;
unsigned long pages;
unsigned char *tmp;
+static struct file* file = NULL;
/* Check the start address: needs to be page-aligned.. */
if (start ~PAGE_CACHE_MASK)
@@ -142,7 +156,7 @@
* the temporary buffer size.
*/
down_read(current-mm-mmap_sem);
- retval = do_mincore(start, tmp, min(pages, PAGE_SIZE));
+ retval = do_mincore(start, tmp, min(pages, PAGE_SIZE), file);
up_read(current-mm-mmap_sem);
if (retval = 0)
Re: Possible Bug in mincore or mmap
Nick Piggin wrote:
> Bruce Dubbs wrote:
>> When testing an installation with tests from the Linux Test Project, my
>> kernels fail one instance of the mincore01 tests:
>>
>> mincoremincore011 PASS : expected failure: errno = 22 (Invalid
>> argument)
>> mincore012 PASS : expected failure: errno = 14 (Bad address)
>> mincore013 FAIL : call succeeded unexpectedly
>> mincore014 PASS : expected failure: errno = 12 (Cannot allocate
>> memory)011 PASS : expected failure: errno = 22 (Invalid argument)
>> mincore012 PASS : expected failure: errno = 14 (Bad address)
>> mincore013 FAIL : call succeeded unexpectedly
>> mincore014 PASS : expected failure: errno = 12 (Cannot allocate
>> memory)
>>
>> I pared down the test to the attached program. The result is supposed
>> to fail as it is asking for memory information 5 times what should be
>> allocated.
>>
>> Upon experimenting, I found the test works properly if a printf is
>> executed before the mmap call. I have tested on locally built, but
>> unmodified, 2.4.25, 2.6.12.5, and a 2.6.20.3 kernels and get the same
>> behavior. The tests fail on IA32 architecture, but not 64-bit kernels.
>> The test always works properly on FC6 and RHEL3.
>>
>> I've checked the archives for this issue and could not find anything
>> appropriate.
>>
>> Could this be a potential security issue as memory that is not supposed
>> to be accessible seems to be available to the user? Is it expected
>> behavior?
>
> It shouldn't be a security problem if mincore doesn't actually
> return the data.
Thanks for the response. It may be interesting to note that adding:
buf = (char*)global_pointer + 2 * global_len;
i = *buf;
after the mincore call does not fail. Changing the 2nd line above to
*buf = 1; gives a segmentation fault as you would expect.
As a minimum, it appears the mmap function is allowing read access
beyond its allocated address space in some circumstances.
Upon thinking about it, it may be that the test is invalid. I don't
believe there is anything tying the mincore query to the memory region
allocated by mmap. If memory mapping occurs beyond the mmap requested
memory size to anticipate another memory request, mincore wouldn't fail.
Does this make any sense?
>>
>>
>> #include
>> #include
>> #include
>> #include
>>
>> static int PAGESIZE;
>> static char file_name[]= "fooXX";
>> static void* global_pointer = NULL;
>> static int global_len = 0;
>> static int file_desc = 0;
>>
>> int main(int argc, char **argv)
>> {
>> int i;
>> int result;
>> char* buf;
>> unsigned char vect[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>>
>> PAGESIZE = getpagesize();
>> /* global_pointer will point to a mmapped area of global_len
>> bytes */
>> global_len = PAGESIZE*2;
>> buf = (char*)malloc(global_len);
>> memset(buf, 42, global_len); // Asterisks /* create a
>> temporary file */
>> file_desc = mkstemp(file_name);
>> /* fill the temporary file with two pages of data */
>> write(file_desc, buf, global_len);
>> free(buf);
>> // Will work properly as long as print is before mmap function.
>> if ( argc > 1 ) printf("argc=%d\n", argc);
>>
>> /* map the file in memory */
>> global_pointer = mmap( NULL, global_len,
>> PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, file_desc, 0);
>>
>> // Result should be -1 as the request is 5 times actual mapping
>> result = mincore(global_pointer, (size_t)(global_len*5), vect);
>>
>> // Print some data
>> printf("PAGESIZE=%d\n", PAGESIZE);
>> printf("global_len=%d\n", global_len);
>> printf("global_pointer=0x%x\n", (unsigned int)global_pointer);
>> printf("alloc=%d\n", (global_len+PAGESIZE-1) / PAGESIZE );
>> printf("Result=%d\n", result);
>> printf("vect: ");
>>
>> for ( i=0; i<20; i++) printf("%02x ", vect[i]);
>> printf("\n");
>> // Clean up
>> munmap(global_pointer, (size_t)global_len);
>> close(file_desc);
>> unlink(file_name);
>> }
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Possible Bug in mincore or mmap
When testing an installation with tests from the Linux Test Project, my
kernels fail one instance of the mincore01 tests:
mincoremincore011 PASS : expected failure: errno = 22 (Invalid
argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)011 PASS : expected failure: errno = 22 (Invalid argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)
I pared down the test to the attached program. The result is supposed
to fail as it is asking for memory information 5 times what should be
allocated.
Upon experimenting, I found the test works properly if a printf is
executed before the mmap call. I have tested on locally built, but
unmodified, 2.4.25, 2.6.12.5, and a 2.6.20.3 kernels and get the same
behavior. The tests fail on IA32 architecture, but not 64-bit kernels.
The test always works properly on FC6 and RHEL3.
I've checked the archives for this issue and could not find anything
appropriate.
Could this be a potential security issue as memory that is not supposed
to be accessible seems to be available to the user? Is it expected
behavior?
Thanks.
-- Bruce
#include
#include
#include
#include
static int PAGESIZE;
static char file_name[]= "fooXX";
static void* global_pointer = NULL;
static int global_len = 0;
static int file_desc = 0;
int main(int argc, char **argv)
{
int i;
int result;
char* buf;
unsigned char vect[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
PAGESIZE = getpagesize();
/* global_pointer will point to a mmapped area of global_len bytes */
global_len = PAGESIZE*2;
buf = (char*)malloc(global_len);
memset(buf, 42, global_len); // Asterisks
/* create a temporary file */
file_desc = mkstemp(file_name);
/* fill the temporary file with two pages of data */
write(file_desc, buf, global_len);
free(buf);
// Will work properly as long as print is before mmap function.
if ( argc > 1 ) printf("argc=%d\n", argc);
/* map the file in memory */
global_pointer = mmap( NULL, global_len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, file_desc, 0);
// Result should be -1 as the request is 5 times actual mapping
result = mincore(global_pointer, (size_t)(global_len*5), vect);
// Print some data
printf("PAGESIZE=%d\n", PAGESIZE);
printf("global_len=%d\n", global_len);
printf("global_pointer=0x%x\n", (unsigned int)global_pointer);
printf("alloc=%d\n", (global_len+PAGESIZE-1) / PAGESIZE );
printf("Result=%d\n", result);
printf("vect: ");
for ( i=0; i<20; i++) printf("%02x ", vect[i]);
printf("\n");
// Clean up
munmap(global_pointer, (size_t)global_len);
close(file_desc);
unlink(file_name);
}
Possible Bug in mincore or mmap
When testing an installation with tests from the Linux Test Project, my
kernels fail one instance of the mincore01 tests:
mincoremincore011 PASS : expected failure: errno = 22 (Invalid
argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)011 PASS : expected failure: errno = 22 (Invalid argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)
I pared down the test to the attached program. The result is supposed
to fail as it is asking for memory information 5 times what should be
allocated.
Upon experimenting, I found the test works properly if a printf is
executed before the mmap call. I have tested on locally built, but
unmodified, 2.4.25, 2.6.12.5, and a 2.6.20.3 kernels and get the same
behavior. The tests fail on IA32 architecture, but not 64-bit kernels.
The test always works properly on FC6 and RHEL3.
I've checked the archives for this issue and could not find anything
appropriate.
Could this be a potential security issue as memory that is not supposed
to be accessible seems to be available to the user? Is it expected
behavior?
Thanks.
-- Bruce
#include sys/mman.h
#include stdlib.h
#include string.h
#include stdio.h
static int PAGESIZE;
static char file_name[]= fooXX;
static void* global_pointer = NULL;
static int global_len = 0;
static int file_desc = 0;
int main(int argc, char **argv)
{
int i;
int result;
char* buf;
unsigned char vect[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
PAGESIZE = getpagesize();
/* global_pointer will point to a mmapped area of global_len bytes */
global_len = PAGESIZE*2;
buf = (char*)malloc(global_len);
memset(buf, 42, global_len); // Asterisks
/* create a temporary file */
file_desc = mkstemp(file_name);
/* fill the temporary file with two pages of data */
write(file_desc, buf, global_len);
free(buf);
// Will work properly as long as print is before mmap function.
if ( argc 1 ) printf(argc=%d\n, argc);
/* map the file in memory */
global_pointer = mmap( NULL, global_len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, file_desc, 0);
// Result should be -1 as the request is 5 times actual mapping
result = mincore(global_pointer, (size_t)(global_len*5), vect);
// Print some data
printf(PAGESIZE=%d\n, PAGESIZE);
printf(global_len=%d\n, global_len);
printf(global_pointer=0x%x\n, (unsigned int)global_pointer);
printf(alloc=%d\n, (global_len+PAGESIZE-1) / PAGESIZE );
printf(Result=%d\n, result);
printf(vect: );
for ( i=0; i20; i++) printf(%02x , vect[i]);
printf(\n);
// Clean up
munmap(global_pointer, (size_t)global_len);
close(file_desc);
unlink(file_name);
}
Re: Possible Bug in mincore or mmap
Nick Piggin wrote:
Bruce Dubbs wrote:
When testing an installation with tests from the Linux Test Project, my
kernels fail one instance of the mincore01 tests:
mincoremincore011 PASS : expected failure: errno = 22 (Invalid
argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)011 PASS : expected failure: errno = 22 (Invalid argument)
mincore012 PASS : expected failure: errno = 14 (Bad address)
mincore013 FAIL : call succeeded unexpectedly
mincore014 PASS : expected failure: errno = 12 (Cannot allocate
memory)
I pared down the test to the attached program. The result is supposed
to fail as it is asking for memory information 5 times what should be
allocated.
Upon experimenting, I found the test works properly if a printf is
executed before the mmap call. I have tested on locally built, but
unmodified, 2.4.25, 2.6.12.5, and a 2.6.20.3 kernels and get the same
behavior. The tests fail on IA32 architecture, but not 64-bit kernels.
The test always works properly on FC6 and RHEL3.
I've checked the archives for this issue and could not find anything
appropriate.
Could this be a potential security issue as memory that is not supposed
to be accessible seems to be available to the user? Is it expected
behavior?
It shouldn't be a security problem if mincore doesn't actually
return the data.
Thanks for the response. It may be interesting to note that adding:
buf = (char*)global_pointer + 2 * global_len;
i = *buf;
after the mincore call does not fail. Changing the 2nd line above to
*buf = 1; gives a segmentation fault as you would expect.
As a minimum, it appears the mmap function is allowing read access
beyond its allocated address space in some circumstances.
Upon thinking about it, it may be that the test is invalid. I don't
believe there is anything tying the mincore query to the memory region
allocated by mmap. If memory mapping occurs beyond the mmap requested
memory size to anticipate another memory request, mincore wouldn't fail.
Does this make any sense?
#include sys/mman.h
#include stdlib.h
#include string.h
#include stdio.h
static int PAGESIZE;
static char file_name[]= fooXX;
static void* global_pointer = NULL;
static int global_len = 0;
static int file_desc = 0;
int main(int argc, char **argv)
{
int i;
int result;
char* buf;
unsigned char vect[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
PAGESIZE = getpagesize();
/* global_pointer will point to a mmapped area of global_len
bytes */
global_len = PAGESIZE*2;
buf = (char*)malloc(global_len);
memset(buf, 42, global_len); // Asterisks /* create a
temporary file */
file_desc = mkstemp(file_name);
/* fill the temporary file with two pages of data */
write(file_desc, buf, global_len);
free(buf);
// Will work properly as long as print is before mmap function.
if ( argc 1 ) printf(argc=%d\n, argc);
/* map the file in memory */
global_pointer = mmap( NULL, global_len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, file_desc, 0);
// Result should be -1 as the request is 5 times actual mapping
result = mincore(global_pointer, (size_t)(global_len*5), vect);
// Print some data
printf(PAGESIZE=%d\n, PAGESIZE);
printf(global_len=%d\n, global_len);
printf(global_pointer=0x%x\n, (unsigned int)global_pointer);
printf(alloc=%d\n, (global_len+PAGESIZE-1) / PAGESIZE );
printf(Result=%d\n, result);
printf(vect: );
for ( i=0; i20; i++) printf(%02x , vect[i]);
printf(\n);
// Clean up
munmap(global_pointer, (size_t)global_len);
close(file_desc);
unlink(file_name);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
