Hi All,
These check the rule DO NOT USE FLOATING POINT IN THE KERNEL on the
2.4.4 and 2.4.4-ac8 releases. There were 10 errors in all:
2.4.4-specific errors = 8
Common errors = 2
--
Hi All,
Enclosed are 24 bugs where code uses memory that has been freed. The
good thing about these bugs is that they are easy to fix. (Note: About
5 of these have had patches submitted, so this list is a bit out of
date.)
Summary
2.4.4ac8-specific errors = 4
2.4.4-specific
Hi All,
Here are 37 errors where variables = 1024 bytes are allocated on a function's
stack.
Summary for
2.4.4ac8-specific errors = 9
2.4.4-specific errors = 0
Common errors = 28
Hi All,
Enclosed are 103 potential errors where code gets a pointer from a
possibly-failing routine (kmalloc, etc) and dereferences it without
checking. Many follow the simple pattern of alloc-memset:
private = kmalloc(sizeof(*private),GFP_KERNEL);
memset(private, 0,
Hi All,
This checker warns when you do not free allocated memory on failure paths.
The error messages with type=SECURITY were emitted when the error path
was triggered by a failed copy_*_user or eqvuivalent --- bad people can
easily use these to make the kernel lose memory.
Summary for
Hi All,
Enclosed are 10 probable security holes where code treats a pointer as
a bad user pointer in one place (by passing it as an argument to a
*_user or verify_area routine) but then dereferences it, or passes it
to a routine that does dereference it somewhere else.
We've reported many of
These are all now either fixed or obsoleted in my tree, and I will send a
patch to Linus shortly. Thankyou.
Good deal. Thanks for letting us know!
Do you find it useful to get a response such as this? Are you keeping track
of the bugs you find? (Or is it simply reassuring to confirm that
check_nmi_watchdog() is __init and we know exactly when it's called.
The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the substring init in them ;-)
Please, don't. These functions are often used from/as init_module(),
so they must handle the case when
Disagree
ahc = ahc_alloc(NULL, name);
ahc_alloc frees name on error
Wow. That would have been a really nasty fix. Sorry about that -- the
name ahc_alloc is a little counter-intuitive ;-)
Thanks for the quick feedback.
Dawson
-
To unsubscribe from this list: send the line
Hi All,
enclosed are 84 potential errors where code
(1) checks if a pointer is null
(2) dereferences it anyway.
For example the code:
Start -- if (!(result = iget(dir-i_sb, ino))) {
hpfs_unlock_iget(dir-i_sb);
Error ---
Hi All,
Enclosed are four bugs where 2.4.4-ac8 kernel code appears to directly
read/write user space pointers. The latter three were found after
forming equivalence classes by:
(1) recording all routines assigned to the same function pointer
field in a structure
(2)
Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a
non-__init function calls an __init function (suggested by
[EMAIL PROTECTED]). There seem to be two cases:
1. The best case: the caller should actually be an __init function
as well. This is a performance
Here are two new uses of floating point that popped up in the 2.4.5-ac4
kernel. While the expressions that use FP are trivial, at least my
version of gcc does not calculate them at compile time.
As a bonus, two old, but still existing FP uses are also included.
Dawson
MC linux bug database:
drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn
'DoC_Probe' calling init fn 'doccheck'
Strictly speaking, not actually a bug. DoC_Probe() itself is only ever
called from __init code. But it's probably not worth trying to make the
checker notice that situation - I've fixed
These are actual (performance) bugs.
Patch is appended.
Thanks for the quick feedback!
BTW: I don't if you did so already, but if you extended the checker to
find functions which are only called from __init functions, but not
marked __init themselves, you'd most likely find lots more
Is there an easy way to tell which routines must be re-entrant?
(it doesn't have to be exhaustive, even an incomplete set is useful)
I was going to write a checker to make sure supposedly re-entrant
routines actually were, but was having a hard time figuring out which
ones were supposed to
Hi All,
Here's a few apparent security holes in 2.4.5-ac4. The biggest is in
fs/ioctl.c where it looks like a new option was added that seems to
write directly to the user pointer, essentially giving anyone complete
control over the machine.
4 | drivers/net/wan/cosa.c
2 |
Three use-after-free bugs:
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/net/rose/rose_dev.c:127:rose_rebuild_header:
ERROR:FREE:122:127: Use-after-free of 'skbn'! set by 'kfree_skb':122
skb_set_owner_w(skbn, skb-sk);
Hi All,
Enclosed is a potential security hole in 2.4.5-ac where an integer from
user space is used as a length argument to copy_to_user.
Additionally, do people have suggestions for good security rules?
We're looking to expand our security checkers. Right now we just have
checkers that warn
[BUG] raddr seems to be a user pointer, but is written at the end of
the system call.
ipc/shm.c: ERROR: system call 'sys_shmat' derefs non-tainted param= 3
asmlinkage long sys_shmat (int shmid, char *shmaddr, int shmflg, ulong *raddr)
{
struct shmid_kernel
Hi,
I wrote an extension to gcc that does global analysis to determine
which pointers in 2.4.1 are ever treated as user space pointers (i.e,
passed to copy_*_user, verify_area, etc) and then makes sure they are
always treated that way.
It found what looks to be 9 errors, and 3 cases I'm not
Hi,
enclosed are 22 functions in 2.4.1 that appear to allocate stack
variables = 1024 bytes. As usual, please report any false positives
so we can fix our checkers.
Dawson
---
[EMAIL PROTECTED] said:
As usual, please report any false positives so we can fix our
checkers.
Not a false positive, but a false negative:
the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and
tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c.
Looks like you've missed at least one place. Have you marked pointer
arguments of syscalls as tainted? Path in question looks so:
In the exokernel param checker we do, but not for the one in linux ---
most of the pointers seemed to be devices, so I never added it. Afer
your for bug example,
enclosed are 163 potential bugs in 2.4.1 where blocking functions are
called with either interrupts disabled or a spin lock held. The
checker works by:
Here's the file manifest. Apologies.
drivers/atm/idt77105.c
drivers/atm/iphase.c
drivers/atm/uPD98402.c
drivers/block/cciss.c
Request: can the checker check for skb's being freed correctly? The
rules:
If an skb is in interrupt context, call dev_kfree_skb_irq.
If an skb might be in interrupt context, call dev_kfree_skb_any.
If an skb is not in interrupt context, call dev_kfree_skb.
It shouldn't be hard to check
Is it difficult to split it into "interrupts disabled" and "spin lock
held"?
Nope, since it's already done ;-) The suffix of each error message
should say whether it's because you have a spinlock, ints disabled, or
both:
2.4.1/drivers/atm/idt77105.c:153:fetch_stats: ERROR:BLOCK:151:153:
Hi,
after some config problems were fixed, there were 10 additional stack
variables found that were = 1K in size. (Though the two tty_io* ones
are already known.)
Dawson
/u2/engler/mc/oses/linux/2.4.1/drivers/char/tty_io.c:2030:tty_unregister_devfs:
ERROR:VAR:2030:2030: suspicious var
Hi All,
right now we are trying to derive which functions can "reasonably" fail
by examining all call sites and recording the number of times functions
are checked vs not checked. Checking includes comparisions , , != 0
directly:
/* these are all checked uses */
if(foo())
Hi All,
as most people know, there are some number of routines in the kernel
that pass back negative error codes as pointers, essentially
doing the cast:
return (void *)-ENOMEM;
These values are supposed to be checked with the routine IS_ERR:
static inline long IS_ERR(const void
Hi All,
here are 15 probable security holes where user input (e.g. data from
copy_from_user, get_user, etc) is:
1. passed as a length argument to copy_*user (or passed to a
function that does so), OR
2. is used as an array index.
The main difference between this
Hi All,
we're starting to develop a checker that finds deadlocks by (1)
computing all lock acquisition paths and (2) checking if two paths
violate a partial order.
E.g., for two threads T1 and T2:
T1: foo acquires A -- calls bar which tries to acquire B
T2: baz acquires B --
Struct padding is a problem. Really, there shouldn't be any
implicit padding. This causes:
1. security leaks when such structs are copied to userspace
(the implicit padding is uninitialized, and so may contain
a chunk of somebody's private key or password)
2. bloat, when struct
Indeed; the bug in the uuid_strategy which you pointed out in the
random driver wasn't caused by the fact that we were using a
user-specified length (since the length was being capped to a maximum
value of 16). The security bug was that the test was done on a signed
value, and
On Sat, 9 Jun 2001, Alexander Viro wrote:
Another difference from spinlocks is that BKL is recursive. I'm
actually surprised that it didn't show up first.
Good point. Spinlocks (with the exception of read-read locks, of course)
and semaphores will deadlock on recursive use, while the
Sure, it's a pretty interaction. To be sure about the rule: any *_user
call can be treated as an implicit invocation of do_page_fault?
As a first approximation, yes. The exception cases are certain callers
that use kernel addresses and set_fs(KERNEL_DS) in order to fake
arguments to
And if you look a couple lines previous it is blindly dereferenced,
this should have been a clue :-)
There's a lot of places where code checks and then blindly
dereferences, so I don't think that's much of a clue ;-)
Start ---
struct rtable *rt = skb ? (struct rtable*)skb-dst : NULL;
Hi,
in the old days you couldn't call a sleeping function in a module
before doing a MOD_INC or after doing a MOD_DEC. Then some safety nets
were added that made these obsolete (in some number of places). I was
told that people had decided to potentially get rid of all safety
nets. Is this
as per a suggestion from Jonathan ([EMAIL PROTECTED]) I wrote a simple
checker to warn when non-__init functions call __init functions or use
__initdata. Before sending the entire list of "bugs" I want to make
sure they actually are errors rather than bugs in how I understand the
kernel. So,
enclosed are three bugs found in the 2.4.1 kernel by an extension
that checks that kmalloc calls allocate enough memory. It examines all
callsites of the form:
p = [kv]malloc(nbytes);
and issues an error if
sizeof *p nbytes
I think they're all currently harmless because of
copy_from_user should probably have something like
(sizeof(agp_segment) * reserve.seg_count)
as it's size argumenbt rather than
GFP_KERNEL
/u2/engler/mc/oses/linux/2.4.3/drivers/char/agp/agpgart_fe.c:882:agpioc_reserve_
wrap: ERROR:SIZE-CHECK:882:882: segment =
We're looking at making a set of security checkers. Does anyone have
suggestions for good things to go after in addition to the usual
copy_*_user and buffer overrun bugs? For example, are there any
documents that describe the rules for when/how 'capable' is supposed to
be used?
Thanks for any
Hi All,
at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple
checker to warn when the length parameter to copy_*_user was (1) an
integer and (2) not checked 0.
As an example, the ipv6 routine rawv6_geticmpfilter gets an integer 'len'
from user space, checks that it is smaller
Hi All,
These check the rule "DO NOT USE FLOATING POINT IN THE KERNEL" on the
2.4.4 and 2.4.4-ac8 releases. There were 10 errors in all:
2.4.4-specific errors = 8
Common errors = 2
--
Hi All,
Enclosed are 24 bugs where code uses memory that has been freed. The
good thing about these bugs is that they are easy to fix. (Note: About
5 of these have had patches submitted, so this list is a bit out of
date.)
Summary
2.4.4ac8-specific errors = 4
2.4.4-specific
Hi All,
Here are 37 errors where variables >= 1024 bytes are allocated on a function's
stack.
Summary for
2.4.4ac8-specific errors = 9
2.4.4-specific errors = 0
Common errors = 28
Hi All,
Enclosed are 103 potential errors where code gets a pointer from a
possibly-failing routine (kmalloc, etc) and dereferences it without
checking. Many follow the simple pattern of alloc-memset:
private = kmalloc(sizeof(*private),GFP_KERNEL);
memset(private, 0,
Hi All,
This checker warns when you do not free allocated memory on failure paths.
The error messages with "type=SECURITY" were emitted when the error path
was triggered by a failed copy_*_user or eqvuivalent --- bad people can
easily use these to make the kernel lose memory.
Summary
Hi All,
Enclosed are 10 probable security holes where code treats a pointer as
a bad user pointer in one place (by passing it as an argument to a
*_user or verify_area routine) but then dereferences it, or passes it
to a routine that does dereference it somewhere else.
We've reported many of
> These are all now either fixed or obsoleted in my tree, and I will send a
> patch to Linus shortly. Thankyou.
Good deal. Thanks for letting us know!
> Do you find it useful to get a response such as this? Are you keeping track
> of the bugs you find? (Or is it simply reassuring to confirm
> check_nmi_watchdog() is __init and we know exactly when it's called.
> The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the
> > Ah, nice --- I keep meaning to tell the checker to demote its warning
> > about NULL bugs or large stack vars in __init routines and/or routines
> > that have the substring "init" in them ;-)
>
> Please, don't. These functions are often used from/as init_module(),
> so they must handle the
> Disagree
>
> > ahc = ahc_alloc(NULL, name);
>
> ahc_alloc frees name on error
Wow. That would have been a really nasty "fix." Sorry about that -- the
name "ahc_alloc" is a little counter-intuitive ;-)
Thanks for the quick feedback.
Dawson
-
To unsubscribe from this list: send the
Hi All,
enclosed are 84 potential errors where code
(1) checks if a pointer is null
(2) dereferences it anyway.
For example the code:
Start --> if (!(result = iget(dir->i_sb, ino))) {
hpfs_unlock_iget(dir->i_sb);
Error --->
Hi All,
Enclosed are four bugs where 2.4.4-ac8 kernel code appears to directly
read/write user space pointers. The latter three were found after
forming equivalence classes by:
(1) recording all routines assigned to the same function pointer
field in a structure
(2)
Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a
non-__init function calls an __init function (suggested by
[EMAIL PROTECTED]). There seem to be two cases:
1. The best case: the caller should actually be an __init function
as well. This is a performance
Here are two new uses of floating point that popped up in the 2.4.5-ac4
kernel. While the expressions that use FP are trivial, at least my
version of gcc does not calculate them at compile time.
As a bonus, two old, but still existing FP uses are also included.
Dawson
MC linux bug database:
> > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn
> > 'DoC_Probe' calling init fn 'doccheck'
>
> Strictly speaking, not actually a bug. DoC_Probe() itself is only ever
> called from __init code. But it's probably not worth trying to make the
> checker notice that situation -
> These are actual (performance) bugs.
> Patch is appended.
Thanks for the quick feedback!
> BTW: I don't if you did so already, but if you extended the checker to
> find functions which are only called from __init functions, but not
> marked __init themselves, you'd most likely find lots more
Is there an easy way to tell which routines must be re-entrant?
(it doesn't have to be exhaustive, even an incomplete set is useful)
I was going to write a checker to make sure supposedly re-entrant
routines actually were, but was having a hard time figuring out which
ones were supposed to
Hi All,
Here's a few apparent security holes in 2.4.5-ac4. The biggest is in
fs/ioctl.c where it looks like a new option was added that seems to
write directly to the user pointer, essentially giving anyone complete
control over the machine.
4 | drivers/net/wan/cosa.c
2 |
Three use-after-free bugs:
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/net/rose/rose_dev.c:127:rose_rebuild_header:
ERROR:FREE:122:127: Use-after-free of 'skbn'! set by 'kfree_skb':122
skb_set_owner_w(skbn, skb->sk);
Hi All,
Enclosed is a potential security hole in 2.4.5-ac where an integer from
user space is used as a length argument to copy_to_user.
Additionally, do people have suggestions for good security rules?
We're looking to expand our security checkers. Right now we just have
checkers that warn
> > [BUG] raddr seems to be a user pointer, but is written at the end of
> > the system call.
> >
> > ipc/shm.c: ERROR: system call 'sys_shmat' derefs non-tainted param= 3
> >
> > asmlinkage long sys_shmat (int shmid, char *shmaddr, int shmflg, ulong *raddr)
> > {
> >
Hi,
I wrote an extension to gcc that does global analysis to determine
which pointers in 2.4.1 are ever treated as user space pointers (i.e,
passed to copy_*_user, verify_area, etc) and then makes sure they are
always treated that way.
It found what looks to be 9 errors, and 3 cases I'm not
Hi,
enclosed are 22 functions in 2.4.1 that appear to allocate stack
variables >= 1024 bytes. As usual, please report any false positives
so we can fix our checkers.
Dawson
---
> [EMAIL PROTECTED] said:
> > As usual, please report any false positives so we can fix our
> > checkers.
>
> Not a false positive, but a false negative:
>
> the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and
> tty_unregister_devfs, respectively, in the 2.4.2
> Looks like you've missed at least one place. Have you marked pointer
> arguments of syscalls as tainted? Path in question looks so:
In the exokernel param checker we do, but not for the one in linux ---
most of the pointers seemed to be devices, so I never added it. Afer
your for bug example,
> enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> called with either interrupts disabled or a spin lock held. The
> checker works by:
Here's the file manifest. Apologies.
drivers/atm/idt77105.c
drivers/atm/iphase.c
drivers/atm/uPD98402.c
drivers/block/cciss.c
> Request: can the checker check for skb's being freed correctly? The
> rules:
>
> If an skb is in interrupt context, call dev_kfree_skb_irq.
> If an skb might be in interrupt context, call dev_kfree_skb_any.
> If an skb is not in interrupt context, call dev_kfree_skb.
It shouldn't be hard to
> Is it difficult to split it into "interrupts disabled" and "spin lock
> held"?
Nope, since it's already done ;-) The suffix of each error message
should say whether it's because you have a spinlock, ints disabled, or
both:
2.4.1/drivers/atm/idt77105.c:153:fetch_stats: ERROR:BLOCK:151:153:
Hi,
after some config problems were fixed, there were 10 additional stack
variables found that were >= 1K in size. (Though the two tty_io* ones
are already known.)
Dawson
/u2/engler/mc/oses/linux/2.4.1/drivers/char/tty_io.c:2030:tty_unregister_devfs:
ERROR:VAR:2030:2030: suspicious var
Hi All,
right now we are trying to derive which functions can "reasonably" fail
by examining all call sites and recording the number of times functions
are checked vs not checked. Checking includes comparisions <, >, != 0
directly:
/* these are all checked uses */
if(foo())
Hi All,
as most people know, there are some number of routines in the kernel
that pass back negative error codes as pointers, essentially
doing the cast:
return (void *)-ENOMEM;
These values are supposed to be checked with the routine IS_ERR:
static inline long IS_ERR(const void
Hi All,
here are 15 probable security holes where user input (e.g. data from
copy_from_user, get_user, etc) is:
1. passed as a length argument to copy_*user (or passed to a
function that does so), OR
2. is used as an array index.
The main difference between this
Hi All,
we're starting to develop a checker that finds deadlocks by (1)
computing all lock acquisition paths and (2) checking if two paths
violate a partial order.
E.g., for two threads T1 and T2:
T1: foo acquires A --> calls bar which tries to acquire B
T2: baz acquires B -->
> Struct padding is a problem. Really, there shouldn't be any
> implicit padding. This causes:
>
> 1. security leaks when such structs are copied to userspace
>(the implicit padding is uninitialized, and so may contain
>a chunk of somebody's private key or password)
>
> 2. bloat, when
> Indeed; the bug in the uuid_strategy which you pointed out in the
> random driver wasn't caused by the fact that we were using a
> user-specified length (since the length was being capped to a maximum
> value of 16). The security bug was that the test was done on a signed
> value, and
> On Sat, 9 Jun 2001, Alexander Viro wrote:
> >
> > Another difference from spinlocks is that BKL is recursive. I'm
> > actually surprised that it didn't show up first.
>
> Good point. Spinlocks (with the exception of read-read locks, of course)
> and semaphores will deadlock on recursive use,
> > Sure, it's a pretty interaction. To be sure about the rule: any *_user
> > call can be treated as an implicit invocation of do_page_fault?
>
> As a first approximation, yes. The exception cases are certain callers
> that use kernel addresses and set_fs(KERNEL_DS) in order to "fake"
>
> And if you look a couple lines previous it is blindly dereferenced,
> this should have been a clue :-)
There's a lot of places where code checks and then blindly
dereferences, so I don't think that's much of a clue ;-)
> > Start --->
> >struct rtable *rt = skb ? (struct rtable*)skb->dst
Hi,
in the old days you couldn't call a sleeping function in a module
before doing a MOD_INC or after doing a MOD_DEC. Then some safety nets
were added that made these obsolete (in some number of places). I was
told that people had decided to potentially get rid of all safety
nets. Is this
as per a suggestion from Jonathan ([EMAIL PROTECTED]) I wrote a simple
checker to warn when non-__init functions call __init functions or use
__initdata. Before sending the entire list of "bugs" I want to make
sure they actually are errors rather than bugs in how I understand the
kernel. So,
enclosed are three bugs found in the 2.4.1 kernel by an extension
that checks that kmalloc calls allocate enough memory. It examines all
callsites of the form:
p = [kv]malloc(nbytes);
and issues an error if
sizeof *p < nbytes
I think they're all currently harmless because of
copy_from_user should probably have something like
(sizeof(agp_segment) * reserve.seg_count)
as it's size argumenbt rather than
GFP_KERNEL
/u2/engler/mc/oses/linux/2.4.3/drivers/char/agp/agpgart_fe.c:882:agpioc_reserve_
wrap: ERROR:SIZE-CHECK:882:882: segment =
We're looking at making a set of security checkers. Does anyone have
suggestions for good things to go after in addition to the usual
copy_*_user and buffer overrun bugs? For example, are there any
documents that describe the rules for when/how 'capable' is supposed to
be used?
Thanks for any
Hi All,
at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple
checker to warn when the length parameter to copy_*_user was (1) an
integer and (2) not checked < 0.
As an example, the ipv6 routine rawv6_geticmpfilter gets an integer 'len'
from user space, checks that it is smaller
88 matches
Mail list logo
