Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 6月, 2005 1 次提交
  3. 22 6月, 2005 3 次提交
  5. 21 6月, 2005 1 次提交
  7. 20 6月, 2005 2 次提交
  9. 24 5月, 2005 1 次提交
  11. 22 5月, 2005 1 次提交
  13. 21 5月, 2005 2 次提交
  15. 19 5月, 2005 3 次提交
    • D
      AUDIT: Honour audit_backlog_limit again. · fb19b4c6
      由 David Woodhouse 提交于 
      The limit on the number of outstanding audit messages was inadvertently
removed with the switch to queuing skbs directly for sending by a kernel
thread. Put it back again.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      fb19b4c6
    • D
      AUDIT: Send netlink messages from a separate kernel thread · b7d11258
      由 David Woodhouse 提交于 
      netlink_unicast() will attempt to reallocate and will free messages if
the socket's rcvbuf limit is reached unless we give it an infinite 
timeout. So do that, from a kernel thread which is dedicated to spewing
stuff up the netlink socket.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      b7d11258
    • S
      AUDIT: Clean up logging of untrusted strings · 168b7173
      由 Steve Grubb 提交于 
      * If vsnprintf returns -1, it will mess up the sk buffer space accounting. 
This is fixed by not calling skb_put with bogus len values.

* audit_log_hex was a loop that called audit_log_vformat with %02X for each 
character. This is very inefficient since conversion from unsigned character 
to Ascii representation is essentially masking, shifting, and byte lookups. 
Also, the length of the converted string is well known - it's twice the 
original. Fixed by rewriting the function.

* audit_log_untrustedstring had no comments. This makes it hard for 
someone to understand what the string format will be.

* audit_log_d_path was never fixed to use untrustedstring. This could mess
up user space parsers. This was fixed to make a temp buffer, call d_path, 
and log temp buffer using untrustedstring. 

From: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      168b7173
  17. 18 5月, 2005 1 次提交
  19. 14 5月, 2005 3 次提交
  21. 13 5月, 2005 1 次提交
  23. 11 5月, 2005 7 次提交
  25. 06 5月, 2005 5 次提交
  27. 04 5月, 2005 1 次提交
    • H
      [NETLINK]: Synchronous message processing. · 2a0a6ebe
      由 Herbert Xu 提交于 
      Let's recap the problem.  The current asynchronous netlink kernel
message processing is vulnerable to these attacks:

1) Hit and run: Attacker sends one or more messages and then exits
before they're processed.  This may confuse/disable the next netlink
user that gets the netlink address of the attacker since it may
receive the responses to the attacker's messages.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.
c) Restrict/prohibit binding.

2) Starvation: Because various netlink rcv functions were written
to not return until all messages have been processed on a socket,
it is possible for these functions to execute for an arbitrarily
long period of time.  If this is successfully exploited it could
also be used to hold rtnl forever.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.

Firstly let's cross off solution c).  It only solves the first
problem and it has user-visible impacts.  In particular, it'll
break user space applications that expect to bind or communicate
with specific netlink addresses (pid's).

So we're left with a choice of synchronous processing versus
SOCK_STREAM for netlink.

For the moment I'm sticking with the synchronous approach as
suggested by Alexey since it's simpler and I'd rather spend
my time working on other things.

However, it does have a number of deficiencies compared to the
stream mode solution:

1) User-space to user-space netlink communication is still vulnerable.

2) Inefficient use of resources.  This is especially true for rtnetlink
since the lock is shared with other users such as networking drivers.
The latter could hold the rtnl while communicating with hardware which
causes the rtnetlink user to wait when it could be doing other things.

3) It is still possible to DoS all netlink users by flooding the kernel
netlink receive queue.  The attacker simply fills the receive socket
with a single netlink message that fills up the entire queue.  The
attacker then continues to call sendmsg with the same message in a loop.

Point 3) can be countered by retransmissions in user-space code, however
it is pretty messy.

In light of these problems (in particular, point 3), we should implement
stream mode netlink at some point.  In the mean time, here is a patch
that implements synchronous processing.  
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a0a6ebe
  29. 03 5月, 2005 1 次提交
    • C
      [PATCH] add new audit data to last skb · 0dd8e06b
      由 Chris Wright 提交于 
      When adding more formatted audit data to an skb for delivery to userspace,
the kernel will attempt to reuse an skb that has spare room.  However, if
the audit message has already been fragmented to multiple skb's, the search
for spare room in the skb uses the head of the list.  This will corrupt the
audit message with trailing bytes being placed midway through the stream.
Fix is to look at the end of the list.
Signed-off-by: NChris Wright <chrisw@osdl.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      0dd8e06b
  31. 30 4月, 2005 1 次提交
  33. 29 4月, 2005 6 次提交