)]}'
{
  "commit": "e35a12dffd5da67b6ca12bd23eebdd0570592205",
  "tree": "7f6d329788bf8f023b8763c9f3464c6aa881ccf1",
  "parents": [
    "86de3a1118a16dbbbe5fabe9aa20ffb93c072ed5"
  ],
  "author": {
    "name": "Shubham Antil",
    "email": "shubham@octane.security",
    "time": "Wed Oct 07 13:28:07 2026 +0530"
  },
  "committer": {
    "name": "Steffen Klassert",
    "email": "steffen.klassert@secunet.com",
    "time": "Mon Oct 12 10:40:31 2026 +0200"
  },
  "message": "xfrm: zero-initialise km_event in the replay-notify path\n\nxfrm_replay_notify(), xfrm_replay_notify_bmp() and\nxfrm_replay_notify_esn() declare a struct km_event on the stack and\ninitialise only its .event and .data.aevent fields, leaving .seq and\n.portid uninitialised. build_aevent() then builds the XFRM_MSG_NEWAE\nmessage with those fields:\n\n  nlmsg_put(skb, c-\u003eportid, c-\u003eseq, ...)\n\nso the netlink header of a replay event carries uninitialised stack\nvalues rather than defined ones. This was confirmed at runtime rather\nthan by inspection alone: the .seq and .portid carried in that header\nhold values that nothing in the replay path assigns.\n\nThe request-driven paths set these header fields from the requester\n(xfrm_get_ae() / xfrm_new_ae()); only the kernel-originated replay path\nleaves them unset. Zero-initialise the event so the header fields are 0,\nthe correct value for a kernel-originated notification.\n\nFixes: f8cd54884e67 (\"[IPSEC]: Sync series - core changes\")\nReported-by: Giovanni Vignone \u003cgio@octane.security\u003e\nAssisted-by: Claude:claude-opus-4-8\nSigned-off-by: Shubham Antil \u003cshubham@octane.security\u003e\nSigned-off-by: Steffen Klassert \u003csteffen.klassert@secunet.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dbdf8a39dffee7fe5fe478a21ca49b53aa5384ba",
      "old_mode": 33188,
      "old_path": "net/xfrm/xfrm_replay.c",
      "new_id": "9394953247ab93c18abc5b1881a90291c38b0037",
      "new_mode": 33188,
      "new_path": "net/xfrm/xfrm_replay.c"
    }
  ]
}