I sometimes see the term "Gating" or "Gating bugs" in scrum development.
I felt like it is something needs to be fixed before the next sprint.
Am I right?
In most cases, "gating" is essentially synonymous with "blocking"--that is, one thing is stopping something else from proceeding. Along with that, there's an implication of a fence on either side of the gate--in other words, this is not only blocking, but is something that's difficult to side-step or work around, so you can't (for example) just mock out this piece until the bug is fixed.
An obvious example would be something extremely fundamental to everything in the system. For example, let's assume you had a system written in Java, but you were using a customized virtual machine--then somebody tried to optimize (say) the memory allocator, but introduced a bug so that attempting to allocate an object, is liable to crash the whole system. You can't really mock out memory allocation and you can't test anything reliably. You're up against the wall, and can't proceed any further until the bug is fixed.
[No, I don't mean to pick on Java in particular--another virtual machine that's available in open-source form could lead to exactly the same sort of problem just as easily, and of course there are all sorts of other problems as well--this just happens to be a particularly extreme example.]
The term "gating bug" or "gating" isn't part of the Scrum terminology. A gate is something that is blocking forward progress. A similar term is "blocking bug".
A common use of gate in project management is the phase-gate model, which defines clear and distinct phases of the project and has gates that the project must pass through in order to be allowed to continue. It's different than an example of a bug, since a gate is often a planned activity and not something that is discovered or arises during the course of a project.