<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/sctp/sm_sideeffect.c, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-12-03T11:45:17Z</updated>
<entry>
<title>sctp: get netns from asoc and ep base</title>
<updated>2025-12-03T11:45:17Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2019-12-09T05:45:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=203a0dace3e2221d3cd110491aebe99b02de8bed'/>
<id>urn:sha1:203a0dace3e2221d3cd110491aebe99b02de8bed</id>
<content type='text'>
[ Upstream commit 4e7696d90b51a1a73ce0e8174f3aff58b914619c ]

Commit 312434617cb1 ("sctp: cache netns in sctp_ep_common") set netns
in asoc and ep base since they're created, and it will never change.
It's a better way to get netns from asoc and ep base, comparing to
calling sock_net().

This patch is to replace them.

v1-&gt;v2:
  - no change.

Suggested-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Stable-dep-of: 1534ff77757e ("sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sctp: handle invalid error codes without calling BUG()</title>
<updated>2023-09-23T08:59:39Z</updated>
<author>
<name>Dan Carpenter</name>
</author>
<published>2023-06-09T11:04:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f31618e4fc0005742bb4035e632380b4478c4294'/>
<id>urn:sha1:f31618e4fc0005742bb4035e632380b4478c4294</id>
<content type='text'>
[ Upstream commit a0067dfcd9418fd3b0632bc59210d120d038a9c6 ]

The sctp_sf_eat_auth() function is supposed to return enum sctp_disposition
values but if the call to sctp_ulpevent_make_authkey() fails, it returns
-ENOMEM.

This results in calling BUG() inside the sctp_side_effects() function.
Calling BUG() is an over reaction and not helpful.  Call WARN_ON_ONCE()
instead.

This code predates git.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sctp: check asoc strreset_chunk in sctp_generate_reconf_event</title>
<updated>2022-05-09T07:03:24Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2022-04-20T20:52:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c45180375afd56382b4387ac7610c6edf182804d'/>
<id>urn:sha1:c45180375afd56382b4387ac7610c6edf182804d</id>
<content type='text'>
[ Upstream commit 165e3e17fe8fe6a8aab319bc6e631a2e23b9a857 ]

A null pointer reference issue can be triggered when the response of a
stream reconf request arrives after the timer is triggered, such as:

  send Incoming SSN Reset Request ---&gt;
  CPU0:
   reconf timer is triggered,
   go to the handler code before hold sk lock
                            &lt;--- reply with Outgoing SSN Reset Request
  CPU1:
   process Outgoing SSN Reset Request,
   and set asoc-&gt;strreset_chunk to NULL
  CPU0:
   continue the handler code, hold sk lock,
   and try to hold asoc-&gt;strreset_chunk, crash!

In Ying Xu's testing, the call trace is:

  [ ] BUG: kernel NULL pointer dereference, address: 0000000000000010
  [ ] RIP: 0010:sctp_chunk_hold+0xe/0x40 [sctp]
  [ ] Call Trace:
  [ ]  &lt;IRQ&gt;
  [ ]  sctp_sf_send_reconf+0x2c/0x100 [sctp]
  [ ]  sctp_do_sm+0xa4/0x220 [sctp]
  [ ]  sctp_generate_reconf_event+0xbd/0xe0 [sctp]
  [ ]  call_timer_fn+0x26/0x130

This patch is to fix it by returning from the timer handler if asoc
strreset_chunk is already set to NULL.

Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer")
Reported-by: Ying Xu &lt;yinxu@redhat.com&gt;
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sctp: change to hold/put transport for proto_unreach_timer</title>
<updated>2020-11-24T12:28:59Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2020-11-14T05:22:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=04b7fd7609b3c9dde027eef81e506bd20df7f506'/>
<id>urn:sha1:04b7fd7609b3c9dde027eef81e506bd20df7f506</id>
<content type='text'>
[ Upstream commit 057a10fa1f73d745c8e69aa54ab147715f5630ae ]

A call trace was found in Hangbin's Codenomicon testing with debug kernel:

  [ 2615.981988] ODEBUG: free active (active state 0) object type: timer_list hint: sctp_generate_proto_unreach_event+0x0/0x3a0 [sctp]
  [ 2615.995050] WARNING: CPU: 17 PID: 0 at lib/debugobjects.c:328 debug_print_object+0x199/0x2b0
  [ 2616.095934] RIP: 0010:debug_print_object+0x199/0x2b0
  [ 2616.191533] Call Trace:
  [ 2616.194265]  &lt;IRQ&gt;
  [ 2616.202068]  debug_check_no_obj_freed+0x25e/0x3f0
  [ 2616.207336]  slab_free_freelist_hook+0xeb/0x140
  [ 2616.220971]  kfree+0xd6/0x2c0
  [ 2616.224293]  rcu_do_batch+0x3bd/0xc70
  [ 2616.243096]  rcu_core+0x8b9/0xd00
  [ 2616.256065]  __do_softirq+0x23d/0xacd
  [ 2616.260166]  irq_exit+0x236/0x2a0
  [ 2616.263879]  smp_apic_timer_interrupt+0x18d/0x620
  [ 2616.269138]  apic_timer_interrupt+0xf/0x20
  [ 2616.273711]  &lt;/IRQ&gt;

This is because it holds asoc when transport-&gt;proto_unreach_timer starts
and puts asoc when the timer stops, and without holding transport the
transport could be freed when the timer is still running.

So fix it by holding/putting transport instead for proto_unreach_timer
in transport, just like other timers in transport.

v1-&gt;v2:
  - Also use sctp_transport_put() for the "out_unlock:" path in
    sctp_generate_proto_unreach_event(), as Marcelo noticed.

Fixes: 50b5d6ad6382 ("sctp: Fix a race between ICMP protocol unreachable and connect()")
Reported-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Link: https://lore.kernel.org/r/102788809b554958b13b95d33440f5448113b8d6.1605331373.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sctp: Fix COMM_LOST/CANT_STR_ASSOC err reporting on big-endian platforms</title>
<updated>2020-11-10T11:37:26Z</updated>
<author>
<name>Petr Malat</name>
</author>
<published>2020-10-30T13:26:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9b5458effeeefa503dab92fc397bb9d0230c8db1'/>
<id>urn:sha1:9b5458effeeefa503dab92fc397bb9d0230c8db1</id>
<content type='text'>
[ Upstream commit b6df8c81412190fbd5eaa3cec7f642142d9c16cd ]

Commit 978aa0474115 ("sctp: fix some type cast warnings introduced since
very beginning")' broke err reading from sctp_arg, because it reads the
value as 32-bit integer, although the value is stored as 16-bit integer.
Later this value is passed to the userspace in 16-bit variable, thus the
user always gets 0 on big-endian platforms. Fix it by reading the __u16
field of sctp_arg union, as reading err field would produce a sparse
warning.

Fixes: 978aa0474115 ("sctp: fix some type cast warnings introduced since very beginning")
Signed-off-by: Petr Malat &lt;oss@malat.biz&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Link: https://lore.kernel.org/r/20201030132633.7045-1-oss@malat.biz
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sctp: Don't add the shutdown timer if its already been added</title>
<updated>2020-06-03T06:21:02Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2020-05-19T20:04:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=70989e501fbce502198d82da88358ce453575a05'/>
<id>urn:sha1:70989e501fbce502198d82da88358ce453575a05</id>
<content type='text'>
[ Upstream commit 20a785aa52c82246055a089e55df9dac47d67da1 ]

This BUG halt was reported a while back, but the patch somehow got
missed:

PID: 2879   TASK: c16adaa0  CPU: 1   COMMAND: "sctpn"
 #0 [f418dd28] crash_kexec at c04a7d8c
 #1 [f418dd7c] oops_end at c0863e02
 #2 [f418dd90] do_invalid_op at c040aaca
 #3 [f418de28] error_code (via invalid_op) at c08631a5
    EAX: f34baac0  EBX: 00000090  ECX: f418deb0  EDX: f5542950  EBP: 00000000
    DS:  007b      ESI: f34ba800  ES:  007b      EDI: f418dea0  GS:  00e0
    CS:  0060      EIP: c046fa5e  ERR: ffffffff  EFLAGS: 00010286
 #4 [f418de5c] add_timer at c046fa5e
 #5 [f418de68] sctp_do_sm at f8db8c77 [sctp]
 #6 [f418df30] sctp_primitive_SHUTDOWN at f8dcc1b5 [sctp]
 #7 [f418df48] inet_shutdown at c080baf9
 #8 [f418df5c] sys_shutdown at c079eedf
 #9 [f418df70] sys_socketcall at c079fe88
    EAX: ffffffda  EBX: 0000000d  ECX: bfceea90  EDX: 0937af98
    DS:  007b      ESI: 0000000c  ES:  007b      EDI: b7150ae4
    SS:  007b      ESP: bfceea7c  EBP: bfceeaa8  GS:  0033
    CS:  0073      EIP: b775c424  ERR: 00000066  EFLAGS: 00000282

It appears that the side effect that starts the shutdown timer was processed
multiple times, which can happen as multiple paths can trigger it.  This of
course leads to the BUG halt in add_timer getting called.

Fix seems pretty straightforward, just check before the timer is added if its
already been started.  If it has mod the timer instead to min(current
expiration, new expiration)

Its been tested but not confirmed to fix the problem, as the issue has only
occured in production environments where test kernels are enjoined from being
installed.  It appears to be a sane fix to me though.  Also, recentely,
Jere found a reproducer posted on list to confirm that this resolves the
issues

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: jere.leppanen@nokia.com
CC: marcelo.leitner@gmail.com
CC: netdev@vger.kernel.org
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sctp: free cmd-&gt;obj.chunk for the unprocessed SCTP_CMD_REPLY</title>
<updated>2020-01-12T11:21:48Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2020-01-04T06:15:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=50027f1c78abced651d03e2a0d88b7caa2b9a0c2'/>
<id>urn:sha1:50027f1c78abced651d03e2a0d88b7caa2b9a0c2</id>
<content type='text'>
[ Upstream commit be7a7729207797476b6666f046d765bdf9630407 ]

This patch is to fix a memleak caused by no place to free cmd-&gt;obj.chunk
for the unprocessed SCTP_CMD_REPLY. This issue occurs when failing to
process a cmd while there're still SCTP_CMD_REPLY cmds on the cmd seq
with an allocated chunk in cmd-&gt;obj.chunk.

So fix it by freeing cmd-&gt;obj.chunk for each SCTP_CMD_REPLY cmd left on
the cmd seq when any cmd returns error. While at it, also remove 'nomem'
label.

Reported-by: syzbot+107c4aff5f392bf1517f@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sctp: use transport pf_retrans in sctp_do_8_2_transport_strike</title>
<updated>2019-09-04T22:29:21Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2019-09-02T15:24:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=10eb56c582c557c629271f1ee31e15e7a9b2558b'/>
<id>urn:sha1:10eb56c582c557c629271f1ee31e15e7a9b2558b</id>
<content type='text'>
Transport should use its own pf_retrans to do the error_count
check, instead of asoc's. Otherwise, it's meaningless to make
pf_retrans per transport.

Fixes: 5aa93bcf66f4 ("sctp: Implement quick failover draft from tsvwg")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: fix the transport error_count check</title>
<updated>2019-08-14T02:08:20Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2019-08-12T12:49:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a1794de8b92ea6bc2037f445b296814ac826693e'/>
<id>urn:sha1:a1794de8b92ea6bc2037f445b296814ac826693e</id>
<content type='text'>
As the annotation says in sctp_do_8_2_transport_strike():

  "If the transport error count is greater than the pf_retrans
   threshold, and less than pathmaxrtx ..."

It should be transport-&gt;error_count checked with pathmaxrxt,
instead of asoc-&gt;pf_retrans.

Fixes: 5aa93bcf66f4 ("sctp: Implement quick failover draft from tsvwg")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
</content>
</entry>
<entry>
<title>Fix memory leak in sctp_process_init</title>
<updated>2019-06-06T00:11:47Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2019-06-03T20:32:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0a8dd9f67cd0da7dc284f48b032ce00db1a68791'/>
<id>urn:sha1:0a8dd9f67cd0da7dc284f48b032ce00db1a68791</id>
<content type='text'>
syzbot found the following leak in sctp_process_init
BUG: memory leak
unreferenced object 0xffff88810ef68400 (size 1024):
  comm "syz-executor273", pid 7046, jiffies 4294945598 (age 28.770s)
  hex dump (first 32 bytes):
    1d de 28 8d de 0b 1b e3 b5 c2 f9 68 fd 1a 97 25  ..(........h...%
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000a02cebbd&gt;] kmemleak_alloc_recursive include/linux/kmemleak.h:55
[inline]
    [&lt;00000000a02cebbd&gt;] slab_post_alloc_hook mm/slab.h:439 [inline]
    [&lt;00000000a02cebbd&gt;] slab_alloc mm/slab.c:3326 [inline]
    [&lt;00000000a02cebbd&gt;] __do_kmalloc mm/slab.c:3658 [inline]
    [&lt;00000000a02cebbd&gt;] __kmalloc_track_caller+0x15d/0x2c0 mm/slab.c:3675
    [&lt;000000009e6245e6&gt;] kmemdup+0x27/0x60 mm/util.c:119
    [&lt;00000000dfdc5d2d&gt;] kmemdup include/linux/string.h:432 [inline]
    [&lt;00000000dfdc5d2d&gt;] sctp_process_init+0xa7e/0xc20
net/sctp/sm_make_chunk.c:2437
    [&lt;00000000b58b62f8&gt;] sctp_cmd_process_init net/sctp/sm_sideeffect.c:682
[inline]
    [&lt;00000000b58b62f8&gt;] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1384
[inline]
    [&lt;00000000b58b62f8&gt;] sctp_side_effects net/sctp/sm_sideeffect.c:1194
[inline]
    [&lt;00000000b58b62f8&gt;] sctp_do_sm+0xbdc/0x1d60 net/sctp/sm_sideeffect.c:1165
    [&lt;0000000044e11f96&gt;] sctp_assoc_bh_rcv+0x13c/0x200
net/sctp/associola.c:1074
    [&lt;00000000ec43804d&gt;] sctp_inq_push+0x7f/0xb0 net/sctp/inqueue.c:95
    [&lt;00000000726aa954&gt;] sctp_backlog_rcv+0x5e/0x2a0 net/sctp/input.c:354
    [&lt;00000000d9e249a8&gt;] sk_backlog_rcv include/net/sock.h:950 [inline]
    [&lt;00000000d9e249a8&gt;] __release_sock+0xab/0x110 net/core/sock.c:2418
    [&lt;00000000acae44fa&gt;] release_sock+0x37/0xd0 net/core/sock.c:2934
    [&lt;00000000963cc9ae&gt;] sctp_sendmsg+0x2c0/0x990 net/sctp/socket.c:2122
    [&lt;00000000a7fc7565&gt;] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
    [&lt;00000000b732cbd3&gt;] sock_sendmsg_nosec net/socket.c:652 [inline]
    [&lt;00000000b732cbd3&gt;] sock_sendmsg+0x54/0x70 net/socket.c:671
    [&lt;00000000274c57ab&gt;] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2292
    [&lt;000000008252aedb&gt;] __sys_sendmsg+0x80/0xf0 net/socket.c:2330
    [&lt;00000000f7bf23d1&gt;] __do_sys_sendmsg net/socket.c:2339 [inline]
    [&lt;00000000f7bf23d1&gt;] __se_sys_sendmsg net/socket.c:2337 [inline]
    [&lt;00000000f7bf23d1&gt;] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2337
    [&lt;00000000a8b4131f&gt;] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:3

The problem was that the peer.cookie value points to an skb allocated
area on the first pass through this function, at which point it is
overwritten with a heap allocated value, but in certain cases, where a
COOKIE_ECHO chunk is included in the packet, a second pass through
sctp_process_init is made, where the cookie value is re-allocated,
leaking the first allocation.

Fix is to always allocate the cookie value, and free it when we are done
using it.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
CC: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: netdev@vger.kernel.org
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
