)]}'
{
  "commit": "2a0a6ebee1d68552152ae8d4aeda91d806995dec",
  "tree": "a0b77861b3395b4728e75f2b2f92755e0a4777d3",
  "parents": [
    "96c36023434b7b6824b1da72a6b7b1ca61d7310c"
  ],
  "author": {
    "name": "Herbert Xu",
    "email": "herbert@gondor.apana.org.au",
    "time": "Tue May 03 14:55:09 2005 -0700"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Tue May 03 14:55:09 2005 -0700"
  },
  "message": "[NETLINK]: Synchronous message processing.\n\nLet\u0027s recap the problem.  The current asynchronous netlink kernel\nmessage processing is vulnerable to these attacks:\n\n1) Hit and run: Attacker sends one or more messages and then exits\nbefore they\u0027re processed.  This may confuse/disable the next netlink\nuser that gets the netlink address of the attacker since it may\nreceive the responses to the attacker\u0027s messages.\n\nProposed solutions:\n\na) Synchronous processing.\nb) Stream mode socket.\nc) Restrict/prohibit binding.\n\n2) Starvation: Because various netlink rcv functions were written\nto not return until all messages have been processed on a socket,\nit is possible for these functions to execute for an arbitrarily\nlong period of time.  If this is successfully exploited it could\nalso be used to hold rtnl forever.\n\nProposed solutions:\n\na) Synchronous processing.\nb) Stream mode socket.\n\nFirstly let\u0027s cross off solution c).  It only solves the first\nproblem and it has user-visible impacts.  In particular, it\u0027ll\nbreak user space applications that expect to bind or communicate\nwith specific netlink addresses (pid\u0027s).\n\nSo we\u0027re left with a choice of synchronous processing versus\nSOCK_STREAM for netlink.\n\nFor the moment I\u0027m sticking with the synchronous approach as\nsuggested by Alexey since it\u0027s simpler and I\u0027d rather spend\nmy time working on other things.\n\nHowever, it does have a number of deficiencies compared to the\nstream mode solution:\n\n1) User-space to user-space netlink communication is still vulnerable.\n\n2) Inefficient use of resources.  This is especially true for rtnetlink\nsince the lock is shared with other users such as networking drivers.\nThe latter could hold the rtnl while communicating with hardware which\ncauses the rtnetlink user to wait when it could be doing other things.\n\n3) It is still possible to DoS all netlink users by flooding the kernel\nnetlink receive queue.  The attacker simply fills the receive socket\nwith a single netlink message that fills up the entire queue.  The\nattacker then continues to call sendmsg with the same message in a loop.\n\nPoint 3) can be countered by retransmissions in user-space code, however\nit is pretty messy.\n\nIn light of these problems (in particular, point 3), we should implement\nstream mode netlink at some point.  In the mean time, here is a patch\nthat implements synchronous processing.  \n\nSigned-off-by: Herbert Xu \u003cherbert@gondor.apana.org.au\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0f84dd7af2c8d016a6992cf9388289399309b57f",
      "old_mode": 33188,
      "old_path": "kernel/audit.c",
      "new_id": "ac26d4d960d3366d0473ede3533ab89446b75dc3",
      "new_mode": 33188,
      "new_path": "kernel/audit.c"
    },
    {
      "type": "modify",
      "old_id": "5fb70cfa10850ae3d6abed0ad765ea76b7e80b4b",
      "old_mode": 33188,
      "old_path": "net/core/rtnetlink.c",
      "new_id": "6e1ab1e34b2ec70630009aa4b4fd2f4ebac8a35c",
      "new_mode": 33188,
      "new_path": "net/core/rtnetlink.c"
    },
    {
      "type": "modify",
      "old_id": "f86a6259fd12171b1acc512713fff788089cb0f9",
      "old_mode": 33188,
      "old_path": "net/decnet/netfilter/dn_rtmsg.c",
      "new_id": "101ddef9ba9aa2aad76b4c26cb88a98551c7dbc5",
      "new_mode": 33188,
      "new_path": "net/decnet/netfilter/dn_rtmsg.c"
    },
    {
      "type": "modify",
      "old_id": "9e40dffc204f3438e0dbabc1ed89be0031f13449",
      "old_mode": 33188,
      "old_path": "net/ipv4/netfilter/ip_queue.c",
      "new_id": "e5746b674413464f6919d3b8880c30dc18feea42",
      "new_mode": 33188,
      "new_path": "net/ipv4/netfilter/ip_queue.c"
    },
    {
      "type": "modify",
      "old_id": "313c1408da33acbe328f8651ada04e3aa1261b68",
      "old_mode": 33188,
      "old_path": "net/ipv4/tcp_diag.c",
      "new_id": "8faa8948f75c2d67db9643dc07b24af7abc609a5",
      "new_mode": 33188,
      "new_path": "net/ipv4/tcp_diag.c"
    },
    {
      "type": "modify",
      "old_id": "c54830b895939ed78f099978841d48a0d1d4a457",
      "old_mode": 33188,
      "old_path": "net/ipv6/netfilter/ip6_queue.c",
      "new_id": "750943e2d34eed262fe1ccc5d9f276d2ed2fc832",
      "new_mode": 33188,
      "new_path": "net/ipv6/netfilter/ip6_queue.c"
    },
    {
      "type": "modify",
      "old_id": "52b5843937c582f15ffca93f84440ff73d4255d2",
      "old_mode": 33188,
      "old_path": "net/xfrm/xfrm_user.c",
      "new_id": "dab112f1dd8a8c10eec2a044eb75852e2a64335a",
      "new_mode": 33188,
      "new_path": "net/xfrm/xfrm_user.c"
    }
  ]
}