summaryrefslogtreecommitdiffstats
path: root/bin/ls/print.c
diff options
context:
space:
mode:
authormckusick <mckusick@FreeBSD.org>2003-10-16 02:00:12 +0000
committermckusick <mckusick@FreeBSD.org>2003-10-16 02:00:12 +0000
commit0dd6703d54f1ef4f4db724f876ae5354ffd92d50 (patch)
treed0092517192f341403455cd4528a65e75e2a8ff3 /bin/ls/print.c
parent8eb262a2d5cb9805fd1a7ce374beca5787bb43f5 (diff)
downloadFreeBSD-src-0dd6703d54f1ef4f4db724f876ae5354ffd92d50.zip
FreeBSD-src-0dd6703d54f1ef4f4db724f876ae5354ffd92d50.tar.gz
Malloc buckets of size 128 have been having their 64-byte offset
trashed after being freed. This has caused several panics including kern/42277 related to soft updates. Jim Kuhn tracked the problem down to ipfw limit rule processing. In the expiry of dynamic rules, it is possible for an O_LIMIT_PARENT rule to be removed when it still has live children. When the children eventually do expire, a pointer to the (long gone) parent is dereferenced and a count decremented. Since this memory can, and is, allocated for other purposes (in the case of kern/42277 an inodedep structure), chaos ensues. The offset in question in inodedep is the offset of the 16 bit count field in the ipfw2 ipfw_dyn_rule. Submitted by: Jim Kuhn <jkuhn@sandvine.com> Reviewed by: "Evgueni V. Gavrilov" <aquatique@rusunix.org> Reviewed by: Ben Pfountz <netprince@vt.edu> MFC after: 1 week
Diffstat (limited to 'bin/ls/print.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud