<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/ipv6, branch v2.6.22.9</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Fix ipv6 source address handling.</title>
<updated>2007-09-26T17:54:43+00:00</updated>
<author>
<name>Jiri Kosina</name>
<email>jkosina@suse.cz</email>
</author>
<published>2007-09-20T19:56:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=29a2edbba56b39d5a3c268bae58c62234432846f'/>
<id>29a2edbba56b39d5a3c268bae58c62234432846f</id>
<content type='text'>
commit 6ae5f983cf8de769214d2d9e8a783c881eccd4cd in mainline

The commit 95c385 broke proper source address selection for cases in which
there is a address which is makred 'deprecated'. The commit mistakenly
changed ifa-&gt;flags to ifa_result-&gt;flags (probably copy/paste error from a
few lines above) in the 'Rule 3' address selection code.

The patch restores the previous RFC-compliant behavior.

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6ae5f983cf8de769214d2d9e8a783c881eccd4cd in mainline

The commit 95c385 broke proper source address selection for cases in which
there is a address which is makred 'deprecated'. The commit mistakenly
changed ifa-&gt;flags to ifa_result-&gt;flags (probably copy/paste error from a
few lines above) in the 'Rule 3' address selection code.

The patch restores the previous RFC-compliant behavior.

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix IPV6 DAD handling</title>
<updated>2007-09-26T17:54:42+00:00</updated>
<author>
<name>Denis V. Lunev</name>
<email>den@openvz.org</email>
</author>
<published>2007-09-20T19:55:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7556e40bae766944a136b44252118737331513ca'/>
<id>7556e40bae766944a136b44252118737331513ca</id>
<content type='text'>
commit 9e3be4b34364a670bd6e57d2e8c3caabdd8d89f8 in mainline

addrconf_dad_failure calls addrconf_dad_stop which takes referenced address
and drops the count. So, in6_ifa_put perrformed at out: is extra. This
results in message: "Freeing alive inet6 address" and not released dst entries.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Alexey Dobriyan &lt;adobriyan@openvz.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9e3be4b34364a670bd6e57d2e8c3caabdd8d89f8 in mainline

addrconf_dad_failure calls addrconf_dad_stop which takes referenced address
and drops the count. So, in6_ifa_put perrformed at out: is extra. This
results in message: "Freeing alive inet6 address" and not released dst entries.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Alexey Dobriyan &lt;adobriyan@openvz.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix ipv6 double-sock-release with MSG_CONFIRM</title>
<updated>2007-09-26T17:54:42+00:00</updated>
<author>
<name>YOSHIFUJI Hideaki</name>
<email>yoshfuji@linux-ipv6.org</email>
</author>
<published>2007-09-20T19:54:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=781514c16542c6fa307fced47db9bd5d7b49734a'/>
<id>781514c16542c6fa307fced47db9bd5d7b49734a</id>
<content type='text'>
commit 3ef9d943d26dea764f4fecf3767001c90b778b0c in mainline

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3ef9d943d26dea764f4fecf3767001c90b778b0c in mainline

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix IPV6 append OOPS.</title>
<updated>2007-09-26T17:54:42+00:00</updated>
<author>
<name>YOSHIFUJI Hideaki</name>
<email>yoshfuji@linux-ipv6.org</email>
</author>
<published>2007-09-20T19:46:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4674cae0ca5e8e84f416a206116b61217d60c6e3'/>
<id>4674cae0ca5e8e84f416a206116b61217d60c6e3</id>
<content type='text'>
commit e1f52208bb968291f7d9142eff60b62984b4a511 in mainline.

[IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames

Some of skbs in sk-&gt;write_queue do not have skb-&gt;dst because
we do not fill skb-&gt;dst when we allocate new skb in append_data().

BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?

If 100, we should set skb-&gt;dst for every queued skbs.

If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.

*: depends on the place we are discarding the datagram.

I guess should just increment by 1 (or 2).

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e1f52208bb968291f7d9142eff60b62984b4a511 in mainline.

[IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames

Some of skbs in sk-&gt;write_queue do not have skb-&gt;dst because
we do not fill skb-&gt;dst when we allocate new skb in append_data().

BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?

If 100, we should set skb-&gt;dst for every queued skbs.

If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.

*: depends on the place we are discarding the datagram.

I guess should just increment by 1 (or 2).

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>TCP: Do not autobind ports for TCP sockets</title>
<updated>2007-08-31T06:01:51+00:00</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-08-22T04:14:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e061467dc5b4c78d4fe61ea6d7a0c848e22882d7'/>
<id>e061467dc5b4c78d4fe61ea6d7a0c848e22882d7</id>
<content type='text'>
[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after
a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the
socket, but we should never do that for TCP.  Instead we should
just go straight into TCP's sendmsg() code which will do all
of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this
merely brings sendmsg() in line with that.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after
a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the
socket, but we should never do that for TCP.  Instead we should
just go straight into TCP's sendmsg() code which will do all
of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this
merely brings sendmsg() in line with that.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>IPv6: Invalid semicolon after if statement</title>
<updated>2007-08-31T06:01:33+00:00</updated>
<author>
<name>Ilpo Jarvinen</name>
<email>ilpo.jarvinen@helsinki.fi</email>
</author>
<published>2007-08-22T04:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f7d75b68abd28e63dd982bb6748bc5d32a289c42'/>
<id>f7d75b68abd28e63dd982bb6748bc5d32a289c42</id>
<content type='text'>
Author: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;

A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Author: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;

A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>IPV6: Fix kernel panic while send SCTP data with IP fragments</title>
<updated>2007-08-31T06:01:01+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yjwei@cn.fujitsu.com</email>
</author>
<published>2007-08-22T04:01:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6f333f6314bf003ee460abc633ea5037d1e53f06'/>
<id>6f333f6314bf003ee460abc633ea5037d1e53f06</id>
<content type='text'>
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A                             Endpoint B
                               &lt;-------  SCTP DATA (size=1432)
ICMP6 message -------&gt;
(Packet Too Big pmtu=1280)
                               &lt;-------  Resend SCTP DATA (size=1432)
------------kernel panic---------------

 printing eip:
c05be62a
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[&lt;c05be62a&gt;]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)
EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [&lt;c0405e1d&gt;] show_trace_log_lvl+0x1a/0x2f
 [&lt;c0405ecd&gt;] show_stack_log_lvl+0x9b/0xa3
 [&lt;c040608d&gt;] show_registers+0x1b8/0x289
 [&lt;c0406271&gt;] die+0x113/0x246
 [&lt;c0625dbc&gt;] do_page_fault+0x4ad/0x57e
 [&lt;c0624642&gt;] error_code+0x72/0x78
 [&lt;d09bc521&gt;] ip6_output+0x8e5/0xab2 [ipv6]
 [&lt;d09bcec1&gt;] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [&lt;d0a3f2ca&gt;] sctp_v6_xmit+0x248/0x253 [sctp]
 [&lt;d0a3c934&gt;] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [&lt;d0a34bf8&gt;] sctp_outq_flush+0x555/0x587 [sctp]
 [&lt;d0a34d3c&gt;] sctp_retransmit+0xf8/0x10f [sctp]
 [&lt;d0a3d183&gt;] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [&lt;d0a3ece2&gt;] sctp_v6_err+0xcd/0x148 [sctp]
 [&lt;d09cf1ce&gt;] icmpv6_notify+0xe6/0x167 [ipv6]
 [&lt;d09d009a&gt;] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [&lt;d09be240&gt;] ip6_input+0x1dc/0x310 [ipv6]
 [&lt;d09be965&gt;] ipv6_rcv+0x294/0x2df [ipv6]
 [&lt;c05c3789&gt;] netif_receive_skb+0x2d2/0x335
 [&lt;c05c5733&gt;] process_backlog+0x7f/0xd0
 [&lt;c05c58f6&gt;] net_rx_action+0x96/0x17e
 [&lt;c042e722&gt;] __do_softirq+0x64/0xcd
 [&lt;c0406f37&gt;] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 &lt;f3&gt; a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [&lt;c05be62a&gt;] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag-&gt;h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;
====================

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Acked-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@ghostprotocols.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A                             Endpoint B
                               &lt;-------  SCTP DATA (size=1432)
ICMP6 message -------&gt;
(Packet Too Big pmtu=1280)
                               &lt;-------  Resend SCTP DATA (size=1432)
------------kernel panic---------------

 printing eip:
c05be62a
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[&lt;c05be62a&gt;]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)
EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [&lt;c0405e1d&gt;] show_trace_log_lvl+0x1a/0x2f
 [&lt;c0405ecd&gt;] show_stack_log_lvl+0x9b/0xa3
 [&lt;c040608d&gt;] show_registers+0x1b8/0x289
 [&lt;c0406271&gt;] die+0x113/0x246
 [&lt;c0625dbc&gt;] do_page_fault+0x4ad/0x57e
 [&lt;c0624642&gt;] error_code+0x72/0x78
 [&lt;d09bc521&gt;] ip6_output+0x8e5/0xab2 [ipv6]
 [&lt;d09bcec1&gt;] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [&lt;d0a3f2ca&gt;] sctp_v6_xmit+0x248/0x253 [sctp]
 [&lt;d0a3c934&gt;] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [&lt;d0a34bf8&gt;] sctp_outq_flush+0x555/0x587 [sctp]
 [&lt;d0a34d3c&gt;] sctp_retransmit+0xf8/0x10f [sctp]
 [&lt;d0a3d183&gt;] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [&lt;d0a3ece2&gt;] sctp_v6_err+0xcd/0x148 [sctp]
 [&lt;d09cf1ce&gt;] icmpv6_notify+0xe6/0x167 [ipv6]
 [&lt;d09d009a&gt;] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [&lt;d09be240&gt;] ip6_input+0x1dc/0x310 [ipv6]
 [&lt;d09be965&gt;] ipv6_rcv+0x294/0x2df [ipv6]
 [&lt;c05c3789&gt;] netif_receive_skb+0x2d2/0x335
 [&lt;c05c5733&gt;] process_backlog+0x7f/0xd0
 [&lt;c05c58f6&gt;] net_rx_action+0x96/0x17e
 [&lt;c042e722&gt;] __do_softirq+0x64/0xcd
 [&lt;c0406f37&gt;] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00 &lt;f3&gt; a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [&lt;c05be62a&gt;] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag-&gt;h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;
====================

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Acked-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@ghostprotocols.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Netfilter: Fix logging regression</title>
<updated>2007-08-09T21:27:46+00:00</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2007-07-25T15:00:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=36466b3d9baf45b77bda5c09f174816ab763f100'/>
<id>36466b3d9baf45b77bda5c09f174816ab763f100</id>
<content type='text'>
[NETFILTER]: Fix logging regression

Loading one of the LOG target fails if a different target has already
registered itself as backend for the same family. This can affect the
ipt_LOG and ipt_ULOG modules when both are loaded.

Reported and tested by: &lt;t.artem@mailcity.com&gt;
Upstream-commit: 7e2acc7e

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[NETFILTER]: Fix logging regression

Loading one of the LOG target fails if a different target has already
registered itself as backend for the same family. This can affect the
ipt_LOG and ipt_ULOG modules when both are loaded.

Reported and tested by: &lt;t.artem@mailcity.com&gt;
Upstream-commit: 7e2acc7e

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>IPV6: /proc/net/anycast6 unbalanced inet6_dev refcnt</title>
<updated>2007-08-09T21:27:46+00:00</updated>
<author>
<name>David Stevens</name>
<email>dlstevens@us.ibm.com</email>
</author>
<published>2007-02-27T00:28:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=05b1ed7990f79388573430faf4f28c31eeaf377b'/>
<id>05b1ed7990f79388573430faf4f28c31eeaf377b</id>
<content type='text'>
Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Marcus Meissner &lt;meissner@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Marcus Meissner &lt;meissner@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix TCP IPV6 MD5 bug.</title>
<updated>2007-08-09T21:27:30+00:00</updated>
<author>
<name>YOSHIFUJI Hideaki</name>
<email>yoshfuji@linux-ipv6.org</email>
</author>
<published>2007-07-25T04:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=668df9fe157abbc90efc0ca054048300afb5937c'/>
<id>668df9fe157abbc90efc0ca054048300afb5937c</id>
<content type='text'>
[TCPv6] MD5SIG: Ensure to reset allocation count to avoid panic.

After clearing all passwords for IPv6 peers, we need to
set allocation count to zero as well as we free the storage.
Otherwise, we panic when a user trys to (re)add a password.

Discovered and fixed by MIYAJIMA Mitsuharu &lt;miyajima.mitsuharu@anchor.jp&gt;.

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[TCPv6] MD5SIG: Ensure to reset allocation count to avoid panic.

After clearing all passwords for IPv6 peers, we need to
set allocation count to zero as well as we free the storage.
Otherwise, we panic when a user trys to (re)add a password.

Discovered and fixed by MIYAJIMA Mitsuharu &lt;miyajima.mitsuharu@anchor.jp&gt;.

Signed-off-by: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
