netdev - Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8739lusbvz.fsf@devron.myhome.or.jp>
Date:	Thu, 07 Apr 2011 17:29:04 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."

OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> writes:

> David Miller <davem@...emloft.net> writes:
>
>> So fix is something like:
>>
>> 1) Add "int rt_route_iif;" to struct rtable
>>
>> 2) For input routes, always set rt_route_iif to same value as rt_iif
>>
>> 3) For output routes, always set rt_route_iif to zero.  Set rt_iif
>>    as it is done currently.
>>
>> 4) Change rt_is_{output,input}_route() to test rt_route_iif
>>
>> This should fix the bug and not introduce new regressions.
>>
>> Can you write and test such a patch with your test case?
>
> Ok. I'll try, but I'm not sure I understand the above correctly. Well,
> I'll send the patch after testing.

This patch seems to work for avahi-daemon without any warning.

BTW, the above meant change from (there was before) "fl.iif" to
"rt_route_iif"? If so, this patch is not enough. I'm not sure

+	rth->rt_route_iif = 0;
+	rth->rt_iif	= oldflp4->flowi4_oif ? : dev_out->ifindex;

is correct one or not. Please review.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html