)]}'
{
  "commit": "8a226b2cfa776db6011fc84b71578513161cd3d3",
  "tree": "7d9cc6e14f0e99e576f761f82c1d350378ef44e8",
  "parents": [
    "3f8f52982ad020f0704548c46de66bf464d3b967"
  ],
  "author": {
    "name": "Jiri Benc",
    "email": "jbenc@redhat.com",
    "time": "Thu Aug 01 10:41:28 2013 +0200"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Thu Aug 01 14:16:20 2013 -0700"
  },
  "message": "ipv6: prevent race between address creation and removal\n\nThere\u0027s a race in IPv6 automatic addess assignment. The address is created\nwith zero lifetime when it\u0027s added to various address lists. Before it gets\nassigned the correct lifetime, there\u0027s a window where a new address may be\nconfigured. This causes the semi-initiated address to be deleted in\naddrconf_verify.\n\nThis was discovered as a reference leak caused by concurrent run of\n__ipv6_ifa_notify for both RTM_NEWADDR and RTM_DELADDR with the same\naddress.\n\nFix this by setting the lifetime before the address is added to\ninet6_addr_lst.\n\nA few notes:\n\n1. In addrconf_prefix_rcv, by setting update_lft to zero, the\n   if (update_lft) { ... } condition is no longer executed for newly\n   created addresses. This is okay, as the ifp fields are set in\n   ipv6_add_addr now and ipv6_ifa_notify is called (and has been called)\n   through addrconf_dad_start.\n\n2. The removal of the whole block under ifp-\u003elock in inet6_addr_add is okay,\n   too, as tstamp is initialized to jiffies in ipv6_add_addr.\n\nSigned-off-by: Jiri Benc \u003cjbenc@redhat.com\u003e\nSigned-off-by: Jiri Pirko \u003cjiri@resnulli.us\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a0ce957fb671cc80b6baac6b551a511e52e19336",
      "old_mode": 33188,
      "old_path": "net/ipv6/addrconf.c",
      "new_id": "da4241c8c7dafe0004a53ed85dfc270cd3be16ba",
      "new_mode": 33188,
      "new_path": "net/ipv6/addrconf.c"
    }
  ]
}