tach
also called it. Eventually this will double free assorted bus resources.
NULL pointer dereference
File: usr/home/tedu/src/sys/pci/if_ti.c
Function: ti_setmulti
malloc return at 1628 is not checked against NULL.
--
Ted Unangst www.coverity.com
Julian Elischer wrote:
Ted Unangst wrote:
these are results from running Coverity's analysis over Freebsd 4.10
kernel.
two improper loops:
if_ef.c:566 and atapi-all.c
ng_socket.c: possible double free of resp 815 and 870, depending on
caller context. is this possible?
I'm not seein
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Ted Unangst <[EMAIL PROTECTED]> writes:
: aha_isa.c: aha_isa_attach: aha_free free "aha", can't use it
: afterwards, lots of examples.
aha_free doesn't actually free the aha, it just tears down
errors in freebsd 4.10 found by Coverity's analysis.
awi_wep.c:awi_wep_setalgo, algo == sizeof
svr4_signal.c:SVR4_NSIG one larger than TBLSIZ
linprocfs_misc.c:linprocfs_doprocstatus, p_stat == sizeof
ibcs2_msg.c:ibcs2_poll, fd == FD_SETSIZE
if_ray.c:ray_rx_mgt_info, len == NWID_LEN
ciss.c:ciss_cam_
Found during analysis with Coverity's tools. FreeBSD 4.10
atapi-cd.c, everywhere. I understand there was some question of not
being to deal with failure gracefully in ata, but many of these are in
functions like ioctl which can easily report errors.
igmp.c:find_rti
mii.c:mii_phy_probe. device_
these are results from running Coverity's analysis over Freebsd 4.10 kernel.
two improper loops:
if_ef.c:566 and atapi-all.c
ng_socket.c: possible double free of resp 815 and 870, depending on
caller context. is this possible?
if_bfe.c: double call to bfe_release_resources will free lots of stu
Andre Oppermann wrote:
Did you run your entire tool on the FreeBSD tree or is this subset of the
available tests and checks?
It's a small sample of the larger whole. The whole thing isn't as
interesting to look at yet, but I'm working on it.
___
[EMAIL
Bugs found with Coverity's automated analysis. In each case, either the
NULL check is unnecessary, or it's too late because the variable was
already deref'd.
dev/firewire/fwohci.c:dump_db (debugging function)
pp can not be null (crash if it is)
dev/mpt/mpt_pci.c:mpt_detach
a null mpt won't surv
in freebsd 4.10 nfs/nfs_vfsops.c:nfs_mountroot, the handling of swap_mp
is incorrect. the code at line 498 appears useless, and furthermore
uses swap_mp without initialization.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinf
if lapic_create is passed the value 16, it will use it as index into
lapics, with potentially bad results. the check should be if (apic_id >=
MAX_APICID).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To uns
the following code, around line 562 in sys/rpc/rpcclnt.c, exceeds the
bounds of the array. each array is only four bytes, the [4] is too much.
/* Initialize other non-zero congestion variables */
rpc->rc_srtt[0] = rpc->rc_srtt[1] = rpc->rc_srtt[2] = rpc->rc_srtt[3] =
On Fri, 5 Mar 2004, Michael Bushkov wrote:
> Some time ago there was a discussion concerning in-process vs. IPC
> nsswitch implementation. We agreed that we should develop an example of
> IPC implementation and ask for a discussion. We are glad to present you
> sample implementation of the IPC nss
On Fri, 9 Apr 2004, Brandon Erhart wrote:
> Are there any debuggers out there for BSD that will detect the heap/stack
> corruption!?
[standard disclaimer and note about self-promotion goes here :)]
valgrind and electric fence are very good suggestions. my own personal
pet project was adding gua
A few final bugs from Coverity. Most of these are off by one, the RF bug
is malloc'ing the wrong type.
Thanks for looking.
# New errors.
#
-
[UNINSPECTED]
X [BUG]
X [FALSE]
X [UNK
Some more. There are bugs where the code checks for NULL after using the
pointer. Usually means the check should be earlier, or is unnecessary.
# New errors.
#
-
[UNINSPECTED]
X [
These are some more bugs from Coverity. Most look like typos.
# New errors.
#
-
[UNINSPECTED]
X [BUG]
X [FALSE]
X [UNKNOWN]
X [BROKE]
X [SKIP]
/home/tedu/sys/cam/cam_xpt.c|1885|xpt
Hi. These are some bugs found by Coverity in a static analysis run on the
FreeBSD kernel. All these are use after free bugs.
# New errors.
#
-
[UNINSPECTED]
X [BUG]
X [FALSE]
X
On Wed, 14 Jan 2004, Steve Watt wrote:
> I'm trying to see if there's a way to get that information into the
> loader (or the driver) in some way that doesn't require rewriting a file
> in the flash every reboot, to avoid flash write cycles.
>
> I know there's some amount of NVRAM in PCs, but didn
while on the subject, there's a piece of code something like this in
freebsd:
/*
* We hash the name and then some other bit of data that is
* invariant over the dirhash's lifetime. Otherwise names
* differing only in the last byte are placed close to one
* a
can somebody please review/commit this to freebsd? it is most of the
differences to permit openbsd to use the code. it should not change the
code in any functional way.
Index: ufs_dirhash.c
===
RCS file: /home/ncvs/src/sys/ufs/uf
On Sat, 25 Oct 2003, Terry Lambert wrote:
> Why does the benchmark need to be "fixed" for OpenBSD and not
> for any other platform?
openbsd does not have a unified cache between file system (pread) and vm
(mmap) interfaces. in the real world, it's unusual to find an application
that uses both in
On Fri, 24 Oct 2003, Michel TALON wrote:
> What is more interesting is to look at the actual benchmark results in
> http://bulk.fefe.de/scalability/
> in particular the section about mmap benchmarks, the only one where
> OpenBSD shines. However as soon as touching pages is benchmarked
> OpenBSD fa
On Thu, 7 Aug 2003, Robert Watson wrote:
> Neat -- sounds like two good catches given the responses so far. Can we
> expect more such reports forthcoming? This kind of help will be
> invaluable in finishing up the fine-grained locking work. Alternatively,
> do you plan to post the software? Is
On Mon, 11 Aug 2003, John Baldwin wrote:
> You can't ifconfig sk0 until after it attaches. sk0 and sk1 don't
> share locks, so you don't have to worry about the interaction there.
I believe they do share a lock. Each port of a dual port sk appears as an
individual interface, but they share the
On Fri, 8 Aug 2003, David Schultz wrote:
> On Wed, Aug 06, 2003, Ted Unangst wrote:
> > My advisor Dawson Engler has written a deadlock detector, and we'd like
> > some verification. They look like bugs, unless there is some other reason
> > why two call chains cann
one more. This falls into the very improbable category. Ordinarily, I
don't think this is possible because FreeBSD doesn't support hotplug PCI,
so sk attachment can't be raced.
However, assuming I had some hot plug sk card, it seems like running
ifconfig sk0 at just the wrong point during sk1 at
My advisor Dawson Engler has written a deadlock detector, and we'd like
some verification. They look like bugs, unless there is some other reason
why two call chains cannot happen at the same time.
deadlock between ktrace_mtx and sema_mtx. is it possible to call
sema_timewait on ktrace_sema? cal
your handling of -i at least is incorrect. after patching, i get very
wrong results. results vary depending on length of string.
reuelos:/tmp/grep-0.16> ./grep -i fastgrep *
grep.c:fastgrep_t *fg_pattern;
reuelos:/tmp/grep-0.16> ./grep fastgrep *
grep.c:fastgrep_t *fg_pattern;
grep.
28 matches
Mail list logo