It's not so simple

Some obvious heuristics (simple-minded ones: they don't need the tool to have any knowledge of C) will also suffice to produce plausible patches even from the set of changes that do not yet exist in an upstream git tree: it seems to me that things like patches introducing API changes can be reconstructed automatically with fairly high precision. With a bit more work (and a lot more CPU time) you can even produce plausible patches which will compile. (Sure, they probably won't be identical to the upstream patches, but they'd be good enough to bisect against.)

(The more I think about a tool to do automatic patch composition like this, the more useful it seems, and not just for this application either. After all, it's not RHEL-kernel-specific: it's a generalized way of turning giant third-party code drops against git-maintained projects into 'this came from git: this did not: of those, these bits look like they are unrelated'.)