kernel/git/stable/linux-stable.git/net/sctp, branch linux-2.6.39.y

sctp: fix memory leak of the ASCONF queue when free asoc

2011-06-03T00:31:56+00:00

[ Upstream commit 8b4472cc13136d04727e399c6fdadf58d2218b0a ] If an ASCONF chunk is outstanding, then the following ASCONF chunk will be queued for later transmission. But when we free the asoc, we forget to free the ASCONF queue at the same time, this will cause memory leak. Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

SCTP: fix race between sctp_bind_addr_free() and sctp_bind_addr_conflict()

2011-06-03T00:31:55+00:00

[ Upstream commit c182f90bc1f22ce5039b8722e45621d5f96862c2 ] During the sctp_close() call, we do not use rcu primitives to destroy the address list attached to the endpoint. At the same time, we do the removal of addresses from this list before attempting to remove the socket from the port hash As a result, it is possible for another process to find the socket in the port hash that is in the process of being closed. It then proceeds to traverse the address list to find the conflict, only to have that address list suddenly disappear without rcu() critical section. Fix issue by closing address list removal inside RCU critical section. Race can result in a kernel crash with general protection fault or kernel NULL pointer dereference: kernel: general protection fault: 0000 [#1] SMP kernel: RIP: 0010:[] [] sctp_bind_addr_conflict+0x64/0x82 [sctp] kernel: Call Trace: kernel: [] ? sctp_get_port_local+0x17b/0x2a3 [sctp] kernel: [] ? sctp_bind_addr_match+0x33/0x68 [sctp] kernel: [] ? sctp_do_bind+0xd3/0x141 [sctp] kernel: [] ? sctp_bindx_add+0x4d/0x8e [sctp] kernel: [] ? sctp_setsockopt_bindx+0x112/0x4a4 [sctp] kernel: [] ? generic_file_aio_write+0x7f/0x9b kernel: [] ? sctp_setsockopt+0x14f/0xfee [sctp] kernel: [] ? do_sync_write+0xab/0xeb kernel: [] ? fsnotify+0x239/0x282 kernel: [] ? alloc_file+0x18/0xb1 kernel: [] ? compat_sys_setsockopt+0x1a5/0x1d9 kernel: [] ? compat_sys_socketcall+0x143/0x1a4 kernel: [] ? sysenter_dispatch+0x7/0x32 Signed-off-by: Jacek Luczak Acked-by: Vlad Yasevich CC: Eric Dumazet Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Revert wrong fixes for common misspellings

2011-04-27T06:31:11+00:00

These changes were incorrectly fixed by codespell. They were now manually corrected. Signed-off-by: Lucas De Marchi

sctp: fix oops while removed transport still using as retran path

2011-04-13T02:33:51+00:00

Since we can not update retran path to unconfirmed transports, when we remove a peer, the retran path may not be update if the other transports are all unconfirmed, and we will still using the removed transport as the retran path. This may cause panic if retrasnmit happen. Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller

sctp: fix oops when updating retransmit path with DEBUG on

2011-04-13T02:33:50+00:00

commit fbdf501c9374966a56829ecca3a7f25d2b49a305 sctp: Do no select unconfirmed transports for retransmissions Introduced the initial falt. commit d598b166ced20d9b9281ea3527c0e18405ddb803 sctp: Make sure we always return valid retransmit path Solved the problem, but forgot to change the DEBUG statement. Thus it was still possible to dereference a NULL pointer. Signed-off-by: Wei Yongjun Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

Merge branch 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6

2011-04-07T18:14:49+00:00

* 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6: Fix common misspellings

sctp: malloc enough room for asconf-ack chunk

2011-04-02T04:45:51+00:00

Sometime the ASCONF_ACK parameters can equal to the fourfold of ASCONF parameters, this only happend in some special case: ASCONF parameter is : Unrecognized Parameter (4 bytes) ASCONF_ACK parameter should be: Error Cause Indication parameter (8 bytes header) + Error Cause (4 bytes header) + Unrecognized Parameter (4bytes) Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic. Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs EIP: 0060:[] EFLAGS: 00010246 CPU: 0 EIP is at skb_put+0x60/0x70 EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0 ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000) Stack: c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40 c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004 00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960 Call Trace: [] ? sctp_addto_chunk+0x4e/0x89 [sctp] [] sctp_addto_chunk+0x4e/0x89 [sctp] [] sctp_process_asconf+0x32f/0x3d1 [sctp] [] sctp_sf_do_asconf+0xf8/0x173 [sctp] [] sctp_do_sm+0xb8/0x159 [sctp] [] ? sctp_cname+0x0/0x52 [sctp] [] sctp_assoc_bh_rcv+0xac/0xe3 [sctp] [] sctp_inq_push+0x2d/0x30 [sctp] [] sctp_rcv+0x7a7/0x83d [sctp] [] ? ipv4_confirm+0x118/0x125 [] ? nf_iterate+0x34/0x62 [] ? ip_local_deliver_finish+0x0/0x194 [] ? ip_local_deliver_finish+0x0/0x194 [] ip_local_deliver_finish+0xf5/0x194 [] ? ip_local_deliver_finish+0x0/0x194 [] NF_HOOK.clone.1+0x3d/0x44 [] ip_local_deliver+0x3e/0x44 [] ? ip_local_deliver_finish+0x0/0x194 [] ip_rcv_finish+0x29f/0x2c7 [] ? ip_rcv_finish+0x0/0x2c7 [] NF_HOOK.clone.1+0x3d/0x44 [] ip_rcv+0x1f5/0x233 [] ? ip_rcv_finish+0x0/0x2c7 [] __netif_receive_skb+0x310/0x336 [] netif_receive_skb+0x4b/0x51 [] cp_rx_poll+0x1e7/0x29c [8139cp] [] net_rx_action+0x65/0x13a [] __do_softirq+0xa1/0x149 [] ? __do_softirq+0x0/0x149 [] ? irq_exit+0x37/0x72 [] ? do_IRQ+0x81/0x95 [] ? common_interrupt+0x30/0x38 [] ? native_safe_halt+0xa/0xc [] ? default_idle+0x58/0x92 [] ? cpu_idle+0x96/0xb2 [] ? rest_init+0x5d/0x5f [] ? start_kernel+0x34b/0x350 [] ? i386_start_kernel+0xba/0xc1 Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi

sctp: Pass __GFP_NOWARN to hash table allocation attempts.

2011-03-31T00:51:36+00:00

Like DCCP and other similar pieces of code, there are mechanisms here to try allocating smaller hash tables if the allocation fails. So pass in __GFP_NOWARN like the others do instead of emitting a scary message. Reported-by: Dave Jones Signed-off-by: David S. Miller

ipv6: Convert to use flowi6 where applicable.

2011-03-12T23:08:54+00:00

Signed-off-by: David S. Miller