<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/net, branch v2.6.23</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.23</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.23'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2007-10-08T06:44:17Z</updated>
<entry>
<title>[ROSE]: Fix rose.ko oops on unload</title>
<updated>2007-10-08T06:44:17Z</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2007-10-08T06:44:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=891e6a931255238dddd08a7b306871240961a27f'/>
<id>urn:sha1:891e6a931255238dddd08a7b306871240961a27f</id>
<content type='text'>
Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
"[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
transformed rose_loopback_neigh var into statically allocated one.
However, on unload it will be kfree's which can't work.

Steps to reproduce:

	modprobe rose
	rmmod rose

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
 printing eip:
c014c664
*pde = 00000000
Oops: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom
CPU:    0
EIP:    0060:[&lt;c014c664&gt;]    Not tainted VLI
EFLAGS: 00210086   (2.6.23-rc9 #3)
EIP is at kfree+0x48/0xa1
eax: 00000556   ebx: c1734aa0   ecx: f6a5e000   edx: f7082000
esi: 00000000   edi: f9a55d20   ebp: 00200287   esp: f6a5ef28
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000)
Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 
       00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 
       f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 
Call Trace:
 [&lt;f9a5200c&gt;] rose_rt_free+0x1d/0x49 [rose]
 [&lt;f9a5200c&gt;] rose_rt_free+0x1d/0x49 [rose]
 [&lt;f9a51f3f&gt;] rose_exit+0x4c/0xd5 [rose]
 [&lt;c0132c60&gt;] sys_delete_module+0x15e/0x186
 [&lt;c014244a&gt;] remove_vma+0x40/0x45
 [&lt;c01025e6&gt;] sysenter_past_esp+0x8f/0x99
 [&lt;c012bacf&gt;] trace_hardirqs_on+0x118/0x13b
 [&lt;c01025b6&gt;] sysenter_past_esp+0x5f/0x99
 =======================
Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff &lt;8b&gt; 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f 
EIP: [&lt;c014c664&gt;] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[TCP]: Fix MD5 signature handling on big-endian.</title>
<updated>2007-09-28T22:18:35Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-09-28T22:18:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f8ab18d2d987a59ccbf0495032b2aef05b730037'/>
<id>urn:sha1:f8ab18d2d987a59ccbf0495032b2aef05b730037</id>
<content type='text'>
Based upon a report and initial patch by Peter Lieven.

tcp4_md5sig_key and tcp6_md5sig_key need to start with
the exact same members as tcp_md5sig_key.  Because they
are both cast to that type by tcp_v{4,6}_md5_do_lookup().

Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
length instead of a u8, which is what tcp_md5sig_key
uses.  This just so happens to work by accident on
little-endian, but on big-endian it doesn't.

Instead of casting, just place tcp_md5sig_key as the first member of
the address-family specific structures, adjust the access sites, and
kill off the ugly casts.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>fix sctp_del_bind_addr() last argument type</title>
<updated>2007-09-26T16:22:04Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2007-09-26T00:54:32Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=78bd8fbbcd66fc977baa40e7fd838a4461b0f727'/>
<id>urn:sha1:78bd8fbbcd66fc977baa40e7fd838a4461b0f727</id>
<content type='text'>
It gets pointer to fastcall function, expects a pointer to normal
one and calls the sucker.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>SCTP : Add paramters validity check for ASCONF chunk</title>
<updated>2007-09-26T05:55:49Z</updated>
<author>
<name>Wei Yongjun</name>
<email>yjwei@cn.fujitsu.com</email>
</author>
<published>2007-09-19T09:19:52Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6f4c618ddb0e6b7e6d49cfc8134e694be1c0bc9b'/>
<id>urn:sha1:6f4c618ddb0e6b7e6d49cfc8134e694be1c0bc9b</id>
<content type='text'>
If ADDIP is enabled, when an ASCONF chunk is received with ASCONF
paramter length set to zero, this will cause infinite loop.
By the way, if an malformed ASCONF chunk is received, will cause
processing to access memory without verifying.

This is because of not check the validity of parameters in ASCONF chunk.
This patch fixed this.

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
</content>
</entry>
<entry>
<title>SCTP: Clean up OOTB handling and fix infinite loop processing</title>
<updated>2007-09-26T05:55:47Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2007-09-07T20:30:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ece25dfa0991f65c4e1d26beb1c3c45bda4239b8'/>
<id>urn:sha1:ece25dfa0991f65c4e1d26beb1c3c45bda4239b8</id>
<content type='text'>
While processing OOTB chunks as well as chunks with an invalid
length of 0, it was possible to SCTP to get wedged inside an
infinite loop because we didn't catch the condition correctly,
or didn't mark the packet for discard correctly.
This work is based on original findings and work by
Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
</content>
</entry>
<entry>
<title>[SCTP]: Convert bind_addr_list locking to RCU</title>
<updated>2007-09-16T23:03:28Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2007-09-16T23:03:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=559cf710b07c5e2cfa3fb8d8f4a1320fd84c53f9'/>
<id>urn:sha1:559cf710b07c5e2cfa3fb8d8f4a1320fd84c53f9</id>
<content type='text'>
Since the sctp_sockaddr_entry is now RCU enabled as part of
the patch to synchronize sctp_localaddr_list, it makes sense to
change all handling of these entries to RCU.  This includes the
sctp_bind_addrs structure and it's list of bound addresses.

This list is currently protected by an external rw_lock and that
looks like an overkill.  There are only 2 writers to the list:
bind()/bindx() calls, and BH processing of ASCONF-ACK chunks.
These are already seriealized via the socket lock, so they will
not step on each other.  These are also relatively rare, so we
should be good with RCU.

The readers are varied and they are easily converted to RCU.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Acked-by: Sridhar Samdurala &lt;sri@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SCTP]: Add RCU synchronization around sctp_localaddr_list</title>
<updated>2007-09-16T23:02:12Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2007-09-16T23:02:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=293035479942400a7fe8e4f72465d4e4e466b91a'/>
<id>urn:sha1:293035479942400a7fe8e4f72465d4e4e466b91a</id>
<content type='text'>
sctp_localaddr_list is modified dynamically via NETDEV_UP
and NETDEV_DOWN events, but there is not synchronization
between writer (even handler) and readers.  As a result,
the readers can access an entry that has been freed and
crash the sytem.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Acked-by: Sridhar Samdurala &lt;sri@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly</title>
<updated>2007-08-30T17:50:48Z</updated>
<author>
<name>Wei Yongjun</name>
<email>yjwei@cn.fujitsu.com</email>
</author>
<published>2007-08-21T07:50:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=00f1c2df2a1c4903f4daa1333bafeb6dcbc9591d'/>
<id>urn:sha1:00f1c2df2a1c4903f4daa1333bafeb6dcbc9591d</id>
<content type='text'>
PROTOCOL VIOLATION error cause in ABORT is bad encode when make abort
chunk. When SCTP encode ABORT chunk with PROTOCOL VIOLATION error cause,
it just add the error messages to PROTOCOL VIOLATION error cause, the
rest four bytes(struct sctp_paramhdr) is just add to the chunk, not
change the length of error cause. This cause the ABORT chunk to be a bad
format. The chunk is like this:

ABORT chunk
  Chunk type: ABORT (6)
  Chunk flags: 0x00
  Chunk length: 72 (*1)
  Protocol violation cause
    Cause code: Protocol violation (0x000d)
    Cause length: 62 (*2)
    Cause information: 5468652063756D756C61746976652074736E2061636B2062...
    Cause padding: 0000
[Needless] 00030010
Chunk Length(*1) = 72 but Cause length(*2) only 62, not include the
extend 4 bytes.
((72 - sizeof(chunk_hdr)) = 68) != (62 +3) / 4 * 4

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
</content>
</entry>
<entry>
<title>SCTP: properly clean up fragment and ordering queues during FWD-TSN.</title>
<updated>2007-08-29T17:34:33Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2007-07-13T21:01:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ea2dfb3733d53ac98b17756435d1f99e25490357'/>
<id>urn:sha1:ea2dfb3733d53ac98b17756435d1f99e25490357</id>
<content type='text'>
When we recieve a FWD-TSN (meaning the peer has abandoned the data),
we need to clean up any partially received messages that may be
hanging out on the re-assembly or re-ordering queues.  This is
a MUST requirement that was not properly done before.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com.&gt;
</content>
</entry>
<entry>
<title>[NETFILTER]: nf_nat: add symbolic dependency on IPv4 conntrack</title>
<updated>2007-08-08T01:12:01Z</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2007-08-08T01:12:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=591e620693e71e24fb3450a4084217e44b7a60b6'/>
<id>urn:sha1:591e620693e71e24fb3450a4084217e44b7a60b6</id>
<content type='text'>
Loading nf_nat causes the conntrack core to be loaded, but we need IPv4 as
well.

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
