As a side note, that grammar is not written in BNF. Rather, it is written in one of many dialects of "extended" BNF, which includes repetition and optionality operators (`{ … }` and `[ … ]`). BNF only has simple productions. However, the repetition and optional components can be macro-expanded into BNF (using a newly-created non-terminal), and the "extended BNF" is generally considered easier to read. It also corresponds directly to the code in top-down parsers, which may well be the type of parser you are being asked to write.
A context-free grammar can certainly include recursion, even indirect left recursion as exhibited by the grammar in this question. But left recursion does create a problem for a top-down parser, precisely of the nature you suggest: the top-down parser goes into an endless loop adding predictions. Bottom-up parsers do not have this problem because they recognise productions when the production is complete rather than having to predict it before it starts.
However, the grammar as written is not correct, because it does not allow the use of type aliases created with a `typedef` declaration:
typedef struct A { int a; } MyTypeName;
MyTypeName b;
Although the grammar will have no problem with the first line above, it will not be able to parse the second one because `TypeSpecifier` does not have an alternative which allows a single identifier.
The standard C grammar defines *type-specifier* as follows:
> *type-specifier*:<br/>
> **void**<br/>
> **char**<br/>
> **short**<br/>
> **int**<br/>
> **long**<br/>
> **float**<br/>
> **double**<br/>
> **signed**<br/>
> **unsigned**<br/>
> **_Bool**<br/>
> **_Complex**<br/>
> *atomic-type-specifier*<br/>
> *struct-or-union-specifier*<br/>
> *enum-specifier*<br/>
> *typedef-name*<br/>
That's very similar to your grammar with the addition of a few primitives and the `atomic` type marker, but the last line is significantly different. This suggests that there is a typo in your grammar.
As a note, *typedef-name* is just an *identifier*, but not any identifier; it must be an identifier previously declared as a type alias ("typedef"). That restriction cannot be expressed in a context-free grammar, and is one of the little challenges involved in writing a C parser.
If you make the change I suggest, you might run into another issue. The standard C grammar defines *declaration* as follows (condensed into EBNF, which the C standard doesn't use):
> *declaration*:<br/>
> { *declaration-specifier* } [ *init-declarator-list* ] **;**
which differs from your grammar because your grammar's definition of *Declaration* doesn't allow multiple *DeclarationSpecifier*. However, the (possibly accidental) recursion in *TypeSpecifier* in effect turns *TypeSpecifier* into a list, thus allowing
unsigned char uch;
However, the fact that *TypeSpecifier* is a list means that it will also accept things like
int double number;
unsigned struct MyStruct u;
which are not meaningful.
It's possible that the C subset you're expected to write a parser for doesn't include `short char` or `long double`, in which case the lack of repetition won't be a problem. If you do need to handle compound type names, you'll need a rather longer list of valid type names. (The standard C grammar does allow meaningless combinations of *declaration-specifier*, but the text of the standard limits the possible combinations. I think the authors of the standard concluded that it would be far too complicated to try to write the restrictions in BNF, and that it would be easier both for presentation and for implementation to do the check after the parse is complete.)