In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>> This kind of bug is a _really_ horribly thing as we end up with one bit
>> of code thinking a particular structure is 136 bytes and another that it
>> is only 112 bytes.
>>
>> Ideally all places would remember to #include the right "opt_foo.h" file,
>> but I think in practice file containing the variable sized struct should
>> #include it explicitly as a precaution.
>
>Ideally, header files wouldn't have any "variable sized structs" or
>anything else that depends on options. Core headers have to be much
>more careful about this because including an options header nested
>would break most modules and everything outside of the kernel (apart
>from the bug that modules and things outside of the kernel have no
>way to determine the correct value for the option).
I agree.
Suggestions for the best way of fixing "struct ipq" in ip_var.h
hereby solicited.
I can see that MAC just unceremonously put their own field in there,
and I guess that is the most sensible thing to do, despite the
RAM this may cost during a DoS attack.
Objections to this patch:
Index: ip_var.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.66
diff -u -r1.66 ip_var.h
--- ip_var.h 16 Oct 2002 01:54:44 -0000 1.66
+++ ip_var.h 16 Oct 2002 07:35:44 -0000
@@ -68,10 +68,8 @@
u_short ipq_id; /* sequence id for reassembly */
struct mbuf *ipq_frags; /* to ip headers of fragments */
struct in_addr ipq_src,ipq_dst;
-#ifdef IPDIVERT
u_int32_t ipq_div_info; /* ipfw divert port & flags */
u_int16_t ipq_div_cookie; /* ipfw divert cookie */
-#endif
struct label ipq_label; /* MAC label */
};
#endif /* _KERNEL */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
