)]}'
{
  "commit": "034e5dbf92ea3a7ea7c9322e47a3a50ff23f7b55",
  "tree": "2fc375b6b887307bac4c0c6ac721bc6b9f663eae",
  "parents": [
    "bcdfa38692d590dda5bc9e4334842abe92ec0ba5"
  ],
  "author": {
    "name": "Ben Wagner",
    "email": "bungeman@chromium.org",
    "time": "Tue Feb 22 20:37:43 2022 -0500"
  },
  "committer": {
    "name": "Werner Lemberg",
    "email": "wl@gnu.org",
    "time": "Wed Feb 23 17:42:55 2022 +0100"
  },
  "message": "[psaux] Full bounds check for OtherSubr 19.\n\nIt is possible for OtherSubr 19 to be invoked when `decoder-\u003ebuildchar` is\nNULL (so that `decoder-\u003elen_buildchar` is 0), the `blend` is non-NULL with\n`blend-\u003enum_designs` set to 2, and the user supplied `idx` to be large (for\nexample 0xFFFFFFFE).  Since these are all `FT_UInt32` the existing bounds\ncheck overflows in a well defined manner, allowing for an invalid call to\n`memcpy`.\n\nIn addition, it is possible to call OtherSubr 19 with\n`decoder-\u003elen_buildchar`, `blend-\u003enum_designs`, and `idx` all zero (implying\nthat `blend-\u003eweight_vector` and `decoder-\u003ebuildchar` are NULL).  This passes\nthe bounds check (it is logically always fine to copy nothing starting at\nindex zero) but may invoke undefined behavior in `ft_memcpy` if it is backed\nby `memcpy`.  Calling `memcpy` with either the `src` or `dst` NULL is\nundefined behavior (even if `count` is zero).\n\n* src/psaux/psintrp.c (cf2_interpT2CharString): Correctly check that\n`blend-\u003enum_designs` can be copied to `decoder-\u003ebuildchar[idx]`.\nAlso avoid passing NULL to `ft_memcpy`.\n\nBug: https://crbug.com/1299259\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c550533a0fcec16ad257df5445252a29b70785f5",
      "old_mode": 33188,
      "old_path": "src/psaux/psintrp.c",
      "new_id": "6c640eebd5a5056a4a41d53305f4798361184e6a",
      "new_mode": 33188,
      "new_path": "src/psaux/psintrp.c"
    }
  ]
}