<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/dccp/input.c, branch v3.15.6</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>net: Fix use after free by removing length arg from sk_data_ready callbacks.</title>
<updated>2014-04-11T20:15:36+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-04-11T20:15:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=676d23690fb62b5d51ba5d659935e9f7d9da9f8e'/>
<id>676d23690fb62b5d51ba5d659935e9f7d9da9f8e</id>
<content type='text'>
Several spots in the kernel perform a sequence like:

	skb_queue_tail(&amp;sk-&gt;s_receive_queue, skb);
	sk-&gt;sk_data_ready(sk, skb-&gt;len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb-&gt;len access is potentially
to freed up memory.

Furthermore, the skb-&gt;len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several spots in the kernel perform a sequence like:

	skb_queue_tail(&amp;sk-&gt;s_receive_queue, skb);
	sk-&gt;sk_data_ready(sk, skb-&gt;len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb-&gt;len access is potentially
to freed up memory.

Furthermore, the skb-&gt;len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Fix (nearly-)kernel-doc comments for various functions</title>
<updated>2012-07-11T06:13:45+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>bhutchings@solarflare.com</email>
</author>
<published>2012-07-10T10:55:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2c53040f018b6c36a46eec75b9b937aaa5f78e6d'/>
<id>2c53040f018b6c36a46eec75b9b937aaa5f78e6d</id>
<content type='text'>
Fix incorrect start markers, wrapped summary lines, missing section
breaks, incorrect separators, and some name mismatches.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix incorrect start markers, wrapped summary lines, missing section
breaks, incorrect separators, and some name mismatches.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: cleanup unsigned to unsigned int</title>
<updated>2012-04-15T16:44:40+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2012-04-15T05:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=95c961747284a6b83a5e2d81240e214b0fa3464d'/>
<id>95c961747284a6b83a5e2d81240e214b0fa3464d</id>
<content type='text'>
Use of "unsigned int" is preferred to bare "unsigned" in net tree.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use of "unsigned int" is preferred to bare "unsigned" in net tree.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: Clean up slow-path input processing</title>
<updated>2011-07-04T18:36:33+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2011-07-03T15:49:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c0c2015056d7bd69f3554208271407e7e2ee69e5'/>
<id>c0c2015056d7bd69f3554208271407e7e2ee69e5</id>
<content type='text'>
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.

 1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
    step 7 is before step 9 (previously 9 was before 7), and parsing options in
    step 8 (which may consume resources) now comes after step 7.
 2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
    note underneath the table in RFC 4340, 7.5.3.
    As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
    i.e. congestion control is performed only on the flow of data packets. This
    avoids pathological cases of doing congestion control on those messages
    which set up and terminate the connection.
 3. Packets are now passed on to Ack Vector / CCID processing only after
    - step 7  (receive unexpected packets),
    - step 9  (receive Reset),
    - step 13 (receive CloseReq),
    - step 14 (receive Close)
    and only if the state is PARTOPEN. This simplifies CCID processing:
    - in LISTEN/CLOSED the CCIDs are non-existent;
    - in RESPOND/REQUEST the CCIDs have not yet been negotiated;
    - in CLOSEREQ and active-CLOSING the node has already closed this socket;
    - in passive-CLOSING the client is waiting for its Reset.
    In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
    data, which is the approach taken here.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.

 1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
    step 7 is before step 9 (previously 9 was before 7), and parsing options in
    step 8 (which may consume resources) now comes after step 7.
 2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
    note underneath the table in RFC 4340, 7.5.3.
    As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
    i.e. congestion control is performed only on the flow of data packets. This
    avoids pathological cases of doing congestion control on those messages
    which set up and terminate the connection.
 3. Packets are now passed on to Ack Vector / CCID processing only after
    - step 7  (receive unexpected packets),
    - step 9  (receive Reset),
    - step 13 (receive CloseReq),
    - step 14 (receive Close)
    and only if the state is PARTOPEN. This simplifies CCID processing:
    - in LISTEN/CLOSED the CCIDs are non-existent;
    - in RESPOND/REQUEST the CCIDs have not yet been negotiated;
    - in CLOSEREQ and active-CLOSING the node has already closed this socket;
    - in passive-CLOSING the client is waiting for its Reset.
    In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
    data, which is the approach taken here.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix oops on Reset after close</title>
<updated>2011-03-02T07:02:07+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2011-03-02T07:02:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=720dc34bbbe9493c7bd48b2243058b4e447a929d'/>
<id>720dc34bbbe9493c7bd48b2243058b4e447a929d</id>
<content type='text'>
This fixes a bug in the order of dccp_rcv_state_process() that still permitted
reception even after closing the socket. A Reset after close thus causes a NULL
pointer dereference by not preventing operations on an already torn-down socket.

 dccp_v4_do_rcv() 
	|
	| state other than OPEN
	v
 dccp_rcv_state_process()
	|
	| DCCP_PKT_RESET
	v
 dccp_rcv_reset()
	|
	v
 dccp_time_wait()

 WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
 Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
 [&lt;c0038850&gt;] (unwind_backtrace+0x0/0xec) from [&lt;c0055364&gt;] (warn_slowpath_common)
 [&lt;c0055364&gt;] (warn_slowpath_common+0x4c/0x64) from [&lt;c0055398&gt;] (warn_slowpath_n)
 [&lt;c0055398&gt;] (warn_slowpath_null+0x1c/0x24) from [&lt;c02b72d0&gt;] (__inet_twsk_hashd)
 [&lt;c02b72d0&gt;] (__inet_twsk_hashdance+0x48/0x128) from [&lt;c031caa0&gt;] (dccp_time_wai)
 [&lt;c031caa0&gt;] (dccp_time_wait+0x40/0xc8) from [&lt;c031c15c&gt;] (dccp_rcv_state_proces)
 [&lt;c031c15c&gt;] (dccp_rcv_state_process+0x120/0x538) from [&lt;c032609c&gt;] (dccp_v4_do_)
 [&lt;c032609c&gt;] (dccp_v4_do_rcv+0x11c/0x14c) from [&lt;c0286594&gt;] (release_sock+0xac/0)
 [&lt;c0286594&gt;] (release_sock+0xac/0x110) from [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380)
 [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380) from [&lt;c02d9a78&gt;] (inet_release+0x64/0x70)

The fix is by testing the socket state first. Receiving a packet in Closed state
now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.

Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Cc: stable@kernel.org
Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug in the order of dccp_rcv_state_process() that still permitted
reception even after closing the socket. A Reset after close thus causes a NULL
pointer dereference by not preventing operations on an already torn-down socket.

 dccp_v4_do_rcv() 
	|
	| state other than OPEN
	v
 dccp_rcv_state_process()
	|
	| DCCP_PKT_RESET
	v
 dccp_rcv_reset()
	|
	v
 dccp_time_wait()

 WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
 Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
 [&lt;c0038850&gt;] (unwind_backtrace+0x0/0xec) from [&lt;c0055364&gt;] (warn_slowpath_common)
 [&lt;c0055364&gt;] (warn_slowpath_common+0x4c/0x64) from [&lt;c0055398&gt;] (warn_slowpath_n)
 [&lt;c0055398&gt;] (warn_slowpath_null+0x1c/0x24) from [&lt;c02b72d0&gt;] (__inet_twsk_hashd)
 [&lt;c02b72d0&gt;] (__inet_twsk_hashdance+0x48/0x128) from [&lt;c031caa0&gt;] (dccp_time_wai)
 [&lt;c031caa0&gt;] (dccp_time_wait+0x40/0xc8) from [&lt;c031c15c&gt;] (dccp_rcv_state_proces)
 [&lt;c031c15c&gt;] (dccp_rcv_state_process+0x120/0x538) from [&lt;c032609c&gt;] (dccp_v4_do_)
 [&lt;c032609c&gt;] (dccp_v4_do_rcv+0x11c/0x14c) from [&lt;c0286594&gt;] (release_sock+0xac/0)
 [&lt;c0286594&gt;] (release_sock+0xac/0x110) from [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380)
 [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380) from [&lt;c02d9a78&gt;] (inet_release+0x64/0x70)

The fix is by testing the socket state first. Receiving a packet in Closed state
now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.

Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Cc: stable@kernel.org
Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix return value for sequence-invalid packets</title>
<updated>2011-01-07T11:22:43+00:00</updated>
<author>
<name>Samuel Jero</name>
<email>sj323707@ohio.edu</email>
</author>
<published>2010-12-30T11:15:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2cf5be93d1b704f342ad423a49f0e78d73939e66'/>
<id>2cf5be93d1b704f342ad423a49f0e78d73939e66</id>
<content type='text'>
Currently dccp_check_seqno returns 0 (indicating a valid packet) if the
acknowledgment number is out of bounds and the sync that RFC 4340 mandates at
this point is currently being rate-limited. This function should return -1,
indicating an invalid packet.

Signed-off-by: Samuel Jero &lt;sj323707@ohio.edu&gt;
Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently dccp_check_seqno returns 0 (indicating a valid packet) if the
acknowledgment number is out of bounds and the sync that RFC 4340 mandates at
this point is currently being rate-limited. This function should return -1,
indicating an invalid packet.

Signed-off-by: Samuel Jero &lt;sj323707@ohio.edu&gt;
Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6</title>
<updated>2010-12-08T21:47:38+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-12-08T21:15:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe6c791570efe717946ea7b7dd50aec96b70d551'/>
<id>fe6c791570efe717946ea7b7dd50aec96b70d551</id>
<content type='text'>
Conflicts:
	drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
	net/llc/af_llc.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
	net/llc/af_llc.c
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix error in updating the GAR</title>
<updated>2010-11-28T19:29:27+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2010-11-23T02:36:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0ac78870220b6e0ac74dd9292bcfa7b18718babd'/>
<id>0ac78870220b6e0ac74dd9292bcfa7b18718babd</id>
<content type='text'>
This fixes a bug in updating the Greatest Acknowledgment number Received (GAR):
the current implementation does not track the greatest received value -
lower values in the range AWL..AWH (RFC 4340, 7.5.1) erase higher ones.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug in updating the Greatest Acknowledgment number Received (GAR):
the current implementation does not track the greatest received value -
lower values in the range AWL..AWH (RFC 4340, 7.5.1) erase higher ones.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp ccid-2: Consolidate Ack-Vector processing within main DCCP module</title>
<updated>2010-11-15T06:11:59+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2010-11-14T16:25:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=18219463c884bfdb7954d298b9edb5194b14d621'/>
<id>18219463c884bfdb7954d298b9edb5194b14d621</id>
<content type='text'>
This aggregates Ack Vector processing (handling input and clearing old state)
into one function, for the following reasons and benefits:
 * all Ack Vector-specific processing is now in one place;
 * duplicated code is removed;
 * ensuring sanity: from an Ack Vector point of view, it is better to clear the
                    old state first before entering new state;
 * Ack Event handling happens mostly within the CCIDs, not the main DCCP module.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This aggregates Ack Vector processing (handling input and clearing old state)
into one function, for the following reasons and benefits:
 * all Ack Vector-specific processing is now in one place;
 * duplicated code is removed;
 * ensuring sanity: from an Ack Vector point of view, it is better to clear the
                    old state first before entering new state;
 * Ack Event handling happens mostly within the CCIDs, not the main DCCP module.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp ccid-2: Algorithm to update buffer state</title>
<updated>2010-11-15T06:11:59+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2010-11-14T16:25:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5753fdfe8bd8e9a2ff9e5af19b0ffc78bfcd502a'/>
<id>5753fdfe8bd8e9a2ff9e5af19b0ffc78bfcd502a</id>
<content type='text'>
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.

While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consistency of the buffer state. These additions are
essential, since analysis and experience showed that the basic algorithm was
insufficient for this task (which lead to problems that were hard to debug).

The algorithm now
 * deals with HC-sender acknowledging to HC-receiver and vice versa,
 * keeps track of the last unacknowledged but received seqno in tail_ackno,
 * has special cases to reset the overflow condition when appropriate,
 * is protected against receiving older information (would mess up buffer state).

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.

While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consistency of the buffer state. These additions are
essential, since analysis and experience showed that the basic algorithm was
insufficient for this task (which lead to problems that were hard to debug).

The algorithm now
 * deals with HC-sender acknowledging to HC-receiver and vice versa,
 * keeps track of the last unacknowledged but received seqno in tail_ackno,
 * has special cases to reset the overflow condition when appropriate,
 * is protected against receiving older information (would mess up buffer state).

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
