On Sunday 2009-11-29 02:43, Adam Nielsen wrote:
>
>>>> Just wondering whether there's still hope for this issue to get fixed.
>>>>
>>>> I haven't added the LED extension to iptables yet, so if there's no
>>>> interest in fixing this, we can remove the LED target again.
>
> I am relying on the xt_tgchk_param passed to the .checkentry function being
> zero'd out the first time. One of the members is a pointer which becomes valid
> when the LED trigger is created, and I'm assuming if that pointer is NULL then
> the LED trigger hasn't yet been created. Providing that iptables sets this
> field to NULL before the first call, and leaves it unchanged when replacing
> rules/tables then it will work fine.
>
>@@ -83,43 +84,52 @@ static void led_timeout_callback(unsigned long data)
> static bool led_tg_check(const struct xt_tgchk_param *par)
> {
> struct xt_led_info *ledinfo = par->targinfo;
>- struct xt_led_info_internal *ledinternal;
>+ struct xt_led_info_internal *ledinternal = ledinfo->internal_data;
> int err;
You cannot rely on ledinfo->internal_data having any meaningful
value when iptables prepares the rule.
1. iptables1 loads ruleset (-j LED exists somewhere)
2. someone does -A INPUT something
3. iptables1 blocks for some reason (say, DNS..)
4. iptables2 loads ruleset (-j LED exists)
5. someone does -D .. -j LED
6. iptables2 submits ruleset
7. iptables1 becomes runnable again and submits ruleset
-> ledinfo->internal_data now points to a freed area.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
