[2948] in Kerberos-V5-bugs
krb5-libs/615: bugs with the handling of ->prev in util/profile library
daemon@ATHENA.MIT.EDU (Chas Williams)
Sat Jul 18 10:56:16 1998
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, chas@cmf.nrl.navy.mil
Date: Sat, 18 Jul 1998 10:47:17 -0400 (EDT)
From: Chas Williams <chas@cmf.nrl.navy.mil>
Reply-To: chas@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Cc: kenh@cmf.nrl.navy.mil
>Number: 615
>Category: krb5-libs
>Synopsis: bugs with the handling of ->prev in util/profile/prof_tree.c
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Jul 18 10:48:00 EDT 1998
>Last-Modified:
>Originator: Chas Williams
>Organization:
Center for Computational Science
Naval Research Laboratory
>Release: 1.0.3
>Environment:
powerpc, macos 8.1
>Description:
in prof_tree.c, in profile_delete_node_relation(), you will see
the following code:
if (p->next)
p->next->prev = p;
profile_free_node(p);
this is obviously wrong, since you assign the p->next->prev to
something with gets freed in the next line. its probably a typo.
the programmer meant to assign p->next->prev to p->prev.
in prof_tree.c, in profile_add_node(), insertion into the middle
of a link list doesnt update the ->prev pointer of the following
list item. in the notation used the source code, imagine a
two item list, with 'last' pointing to the head of the list,
and 'p' pointing to the end of the list. 'new' is the node that
is about to be inserted in between:
from profile_add_node():
new->prev = last;
if (last)
last->next = new;
else
section->first_child = new;
if (p)
new->next = p;
the state before this code is:
-> ->
null last p null
<- <-
'running' the code does the following assignments:
new.prev = last;
last.next = new;
new.next = p;
this gives the following (broken) linked list:
-> -> ->
null last new p null
<- <- /
<-------
p.prev is never changed, and breaks the list the the backward
direction. note that the foward direction is fine, and this
actually doesnt cause problems until one attempts to delete a node
in the middle of the list. p.prev should point to new.
>How-To-Repeat:
this bug appeared in the macintosh 'cns-config' application.
modifying the profile in memory produced strange results (often
crashing) -- its the only kerberos application that uses the
delete_node profile functions (in order to edit the configuration
file via a 'friendly' user interface) hopefully the above is
sufficient.
>Fix:
a context diff follows:
diff -c -r krb5-1.0.3.macos/src/util/profile/prof_tree.c krb5-1.0.3/src/util/profile/prof_tree.c
*** krb5-1.0.3.macos/src/util/profile/prof_tree.c Fri Jul 17 18:32:26 1998
--- krb5-1.0.3/src/util/profile/prof_tree.c Mon Nov 17 22:51:18 1997
***************
*** 166,175 ****
last->next = new;
else
section->first_child = new;
! if (p) {
new->next = p;
- p->prev = new;
- }
if (ret_node)
*ret_node = new;
return 0;
--- 166,173 ----
last->next = new;
else
section->first_child = new;
! if (p)
new->next = p;
if (ret_node)
*ret_node = new;
return 0;
***************
*** 319,325 ****
section->first_child = p->next;
next = p->next;
if (p->next)
! p->next->prev = p->prev;
profile_free_node(p);
p = next;
}
--- 317,323 ----
section->first_child = p->next;
next = p->next;
if (p->next)
! p->next->prev = p;
profile_free_node(p);
p = next;
}
>Audit-Trail:
>Unformatted:
