Why does ORACLE cache recovery create uncommited blocks during instance recovery?
How can a redo log file generate uncommitted data since all its information are recorded after COMMIT ?

LGWR process flushes redo logs from redo log buffer cache to online redo log files when-

A user fire commit explicitly.
One third of space in redo log buffer is filled.
Three seconds of time has passed since last redo flush.
DBWn process writes dirty buffer to disk.

These all triggers redo flush which may include uncommitted transaction.

BUT how can undo blocks can be used to rollback uncommitted changes (what are those changes anyway...) introduced by replaying redo logs during cache recovery ?

Let me give you an example，suppose you have a data block which contains one row with single column with value 5. You simply try to update it using update tbl set col1=6. During this process undo is generated to reproduce it's original value which is 5 and redo is generated to reply the transaction, means to reproduce the latest value which is 6.
Next, if this transaction is uncommitted and unfortunately instance crashes, during the next startup, Oracle(Specifically SMON process) takes the blocks which need to be recovered into the buffer cache and re-apply the changes using redo logs and if someone tries to read the row that you had modified before, Oracle simply rolled back the data block containing the row to its original value which is 5 using undo.
Update:
The following alert log excerpt is extracted from this blog.
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 80458 KB redo, 1721 data blocks need recovery
Started redo application at
Thread 1: logseq 490, block 52626
Recovery of Online Redo Log: Thread 1 Group 1 Seq 490 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo01.log
Recovery of Online Redo Log: Thread 1 Group 2 Seq 491 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo02.log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 492 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl/redo03.log
Completed redo application of 15.26MB
Completed crash recovery at
Thread 1: logseq 492, block 31015, scn 6082434
1721 data blocks read, 1721 data blocks written, 80458 redo k-bytes read
Sun Jan 09 00:50:27 2011

This clearly shows that block number 1721 needs recovery. And in order to do that the block is loaded into the memory(buffer cache) and redo is applied. The block is written back to data file after the recovery.
This is also explained in(Chapter-9 Redo and Undo, How Redo and Undo Work Together, Page ) Expert Oracle Architecture Third Edition book by Thomas Kyte.
From ASKTOM

Hi Tom,

To do the crash recovery , Database needs datablocks(needed recovery) to be brought into SGA. May i know which process will bring them?.

Thanks
Followup
smon will read them and apply redo to them during the recovery phase.

Instance/Crash Recovery