)]}'
{
  "commit": "0c5220d2b70215c6d2f2143fd1cb657d5210a9bf",
  "tree": "fab81e1f4825b8c0d5e00f47a2c63f04497b05da",
  "parents": [
    "56885a5aba2f93658dfbce1f66e99901d84bb5d1"
  ],
  "author": {
    "name": "Kees Cook",
    "email": "kees@kernel.org",
    "time": "Thu Aug 08 11:39:08 2024 -0700"
  },
  "committer": {
    "name": "Michael Kochera",
    "email": "kochera@google.com",
    "time": "Mon Sep 09 16:46:34 2024 +0000"
  },
  "message": "exec: Fix ToCToU between perm check and set-uid/gid usage\n\ncommit f50733b45d865f91db90919f8311e2127ce5a0cb upstream.\n\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0027s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\n\nFor example, if a file could change permissions from executable and not\nset-id:\n\n---------x 1 root root 16048 Aug  7 13:16 target\n\nto set-id and non-executable:\n\n---S------ 1 root root 16048 Aug  7 13:16 target\n\nit is possible to gain root privileges when execution should have been\ndisallowed.\n\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \"chmod o-x,u+s target\" makes \"target\" executable only\nby uid \"root\" and gid \"cdrom\", while also becoming setuid-root:\n\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\n\nbecomes:\n\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\n\nBut racing the chmod means users without group \"cdrom\" membership can\nget the permission to execute \"target\" just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \"only cdrom\ngroup members can setuid to root\".\n\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.\n\nBUG\u003db/364558219\nTEST\u003dpresubmit\nRELEASE_NOTE\u003dFixes CVE-2024-43882 in the Linux kernel\n\ncos-patch: security-high\nReported-by: Marco Vanotti \u003cmvanotti@google.com\u003e\nTested-by: Marco Vanotti \u003cmvanotti@google.com\u003e\nSuggested-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: stable@vger.kernel.org\nCc: Eric Biederman \u003cebiederm@xmission.com\u003e\nCc: Alexander Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christian Brauner \u003cbrauner@kernel.org\u003e\nChange-Id: I28f8b55442c1302eebdb5d6740b100f6787fa1e1\nSigned-off-by: Kees Cook \u003ckees@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nSigned-off-by: Kernel CVE Triage Automation \u003ccloud-image-kernel-cve-triage-automation@prod.google.com\u003e\nReviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/80107\nTested-by: Cusky Presubmit Bot \u003cpresubmit@cos-infra-prod.iam.gserviceaccount.com\u003e\nReviewed-by: Anil Altinay \u003caaltinay@google.com\u003e\nReviewed-by: Michael Kochera \u003ckochera@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b01434d6a512de16e480b70145f83e81730406f6",
      "old_mode": 33188,
      "old_path": "fs/exec.c",
      "new_id": "481b6e7df6ae506d6e6b99a9307537260472ed26",
      "new_mode": 33188,
      "new_path": "fs/exec.c"
    }
  ]
}