)]}'
{
  "commit": "d042487dc118e494db2e2c1382310255c90ff544",
  "tree": "c8835bdb1b8d1d44777303676e3dd7be3904701e",
  "parents": [
    "4e9442ce551ebd84b52ad649df721e2dc28af95a"
  ],
  "author": {
    "name": "Roshan Kumar",
    "email": "roshaen09@gmail.com",
    "time": "Tue Jul 28 10:56:08 2026 +0530"
  },
  "committer": {
    "name": "Steffen Klassert",
    "email": "steffen.klassert@secunet.com",
    "time": "Tue Aug 18 12:15:41 2026 +0200"
  },
  "message": "xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk()\n\niptfs_skb_reset_frag_walk() advances to the fragment containing @offset\nwith an unbounded loop:\n\n\twhile (offset \u003e\u003d walk-\u003epast + walk-\u003efrags[walk-\u003efragi].len)\n\t\twalk-\u003epast +\u003d walk-\u003efrags[walk-\u003efragi++].len;\n\nwalk-\u003efragi is advanced and walk-\u003efrags[walk-\u003efragi] is dereferenced\nwithout ever checking fragi against walk-\u003enr_frags. When the requested\noffset is at or beyond the total length spanned by the walk\u0027s fragments,\nfragi runs past nr_frags and off the end of the fixed-size on-stack\nfrags[MAX_SKB_FRAGS + 1] array, reading out-of-bounds stack memory.\n\nThe two callers behave differently: iptfs_skb_add_frags() already guards\nagainst this with\n\n\tif (!walk-\u003enr_frags ||\n\t    offset \u003e\u003d walk-\u003etotal + walk-\u003einitial_offset)\n\t\treturn len;\n\nbut iptfs_skb_can_add_frags() has no such guard and calls\niptfs_skb_reset_frag_walk() unconditionally, so it performs the\nout-of-range walk. Its own \"fragi \u003c walk-\u003enr_frags\" bound check runs only\nafterwards, too late to prevent the read.\n\nThis is reachable from the receive path: a crafted IP-TFS (AGGFRAG)\npayload delivered to an IPTFS SA drives iptfs_reassem_cont() -\u003e\niptfs_skb_can_add_frags() with an offset past the fragment total, e.g.:\n\n  BUG: KASAN: stack-out-of-bounds in iptfs_skb_reset_frag_walk+0x235/0x250\n  Read of size 4 at addr ffff888008ad7210 by task repro/345\n   iptfs_skb_reset_frag_walk+0x235/0x250 net/xfrm/xfrm_iptfs.c:392\n   iptfs_skb_can_add_frags+0x155/0x310  net/xfrm/xfrm_iptfs.c:420\n   iptfs_reassem_cont+0xcf8/0x1140      net/xfrm/xfrm_iptfs.c:902\n   iptfs_input_ordered+0x552/0x670      net/xfrm/xfrm_iptfs.c:1280\n   iptfs_input+0x3d6/0xde0              net/xfrm/xfrm_iptfs.c:1741\n   xfrm_input+0x282f/0x6140             net/xfrm/xfrm_input.c:700\n   xfrm4_esp_rcv+0x93/0x120             net/ipv4/xfrm4_protocol.c:104\n   ip_rcv+0x278/0x2d0                   net/ipv4/ip_input.c:612\n\nGive iptfs_skb_can_add_frags() the same up-front guard that\niptfs_skb_add_frags() already has, so the walk is never entered with an\nout-of-range offset. When it triggers, the caller falls back to the\nexisting linearize-and-copy path, which is safe.\n\nFixes: 5f2b6a909574 (\"xfrm: iptfs: add skb-fragment sharing code\")\nReported-by: Roshan Kumar \u003croshaen09@gmail.com\u003e\nSigned-off-by: Roshan Kumar \u003croshaen09@gmail.com\u003e\nSigned-off-by: Steffen Klassert \u003csteffen.klassert@secunet.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "597aedeac26ebaae07b46ac49c11400e9b4e6cec",
      "old_mode": 33188,
      "old_path": "net/xfrm/xfrm_iptfs.c",
      "new_id": "2ce15c472cc4db7e0a710d1b8c356e81e7daf318",
      "new_mode": 33188,
      "new_path": "net/xfrm/xfrm_iptfs.c"
    }
  ]
}