Is it significantly easier to reverse a SHA-256 hash if you know that the input was a 32 byte output of SHA-256?
I assume for most outputs of SHA-256 there will be zero, one or two possible 32 byte inputs.
Mapping and storing all of the values is infeasible, but I am still worried that constraining the input to being exactly 32 bytes may weaken SHA-256.
Is this a valid concern?
No, that would not be possible. It would be very weird indeed if a hash was suddenly invertible if the input was of a specific form - it would basically mean that the hash would be broken. Iterating over all the possible values of those 32 bytes is certainly not an option either.
That does not mean that such a structure doesn't have it's peculiarities though, the first link provided by mikazo is a good summary of what to expect.
If you want to avoid such peculiarities then I would suggest you follow the suggestion by CodesInChaos to use a HMAC construct with a fixed key instead of SHA-256 directly. As e.g. length extension attacks not feasible with SHA-3 (Keccak) you can probably use that without reverting to a HMAC.
Is it significantly easier to reverse a sha256 hash if you know that the input was a 32 byte output of sha256?
Assuming a random N-bit input ($N>3256$) versus a 256-bit input, for all practical intents and purposes, the difficultly is extremely difficult (read: not feasible by today's computational capabilities) for both.
If you are talking about a theoretical reversing attack, then you have to understand collisions. There are far fewer collisions that exist when the input is $N=256$ bits versus $N\gg256$ bits, or even when N is unknown. The input space for one is $2^{256}$ and (roughly) $\sum_{i}2^{i}$ (where $i=$ allowed bit sizes) for the other. Yes, there is likely several orders of magnitude more collisions for an output corresponding to the latter case, so you would have to sort through all of them which would be orders of magnitude more difficult. However, as a matter of practicality, this doesn't really matter.
I assume for most outputs of sha256 there will be zero, one or two possible 32 byte inputs.
On average, if you assume 256-bit inputs and outputs, and reasonable randomness, something like 1.5 inputs get mapped to a single output, but some outputs could have more, while others have zero. This leads me to the following point (outside of what you initially asked, but related to the Related Question linked above.
For equal sized inputs and outputs with a (deterministic) function that has random-looking mappings, then if you apply the function to itself $f(f(...f(x)))$, the final output space is certainly less than the input. In fact, the output space it is approximately $2/3$ of the size of the input space after each iteration. So if you apply $f()$ 10 times, then the output space is approximately $(\frac{2}{3})^{10}$, which is less than 2% of the original input space. This sounds horrible, but it really is insignificant when applied with SHA-256. Reducing the brute force attack time of SHA-256 by a order or magnitude or two is insignificant. Crypto and related hash algorithms are not affected by a reduction in security of just a few bits or so. (More info than you wanted, but I'm trying to be complete.)
Is it significantly easier to reverse a sha256 hash if you know that the input was a 32 byte output of SHA-256?
It depends on what you are comparing to.
Is it easier to reverse an SHA-256 hash of some SHA-256 hash than that of a random number? Sure, it can be. For example, it is easy to find that the preimage of
73641c99f7719f57d8f4beb11a303afcd190243a51ced8782ca6d3dbe014d146
is
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
because that happens to be the SHA-256 hash of the ASCII string password. A dictionary attack is easy for such predictable inputs.
However, if you are concerned about whether you can turn $H(H(r))$ into $H(r)$, where $r$ is a large random number/string, then no, there is no practical weakness. There is no loss of security if $r$ is more than 256 bits and unpredictable by the attacker.
