Is there a need to check for NULL after allocating memory, when kernel uses overcommit memory

Yes, you should still check for failures returned by malloc. In an environment that overcommits memory you will not be able to detect and recover from failures due to the environment running out of physical storage required when you write to parts of the address space that have been allocated to your program by a previous call to malloc.

However, this is not the only problem that would cause a malloc to fail in a traditional environment. A request for a particularly large block of memory when the address space of your program has become fragmented may fail even if there is potentially enough total physical memory to satisfy the request. Because there is no contiguous range of free address space malloc must fail. This type of failure must be signaled by malloc returning NULL, whether or not the environment is overcommitting memory.

You must check return value for NULL every time. Any library function can fail. Even fclose() do (on disconnected NFS share, and error from fclose of NFS file means, that data was not saved).

The most of software is badly written and doesn't contain all checks.

malloc can't return something other than NULL or pointer. All-or-nothing. You can't get 1 byte from malloc if you ask for 10.

It would be advisable to check for NULL religiously across all functions calls that may return NULL, regardless of whether the kernel has over-committable memory or not.

This following code segment below shows how to check if the call to malloc worked or not...

void *ptr = malloc(10);
if (ptr != NULL){
   /* Do something here with ptr */
}else{
   /* Do something here if it fails */
}

File operations, memory operations to name but a few will return a NULL upon failure.

Hope this helps, Best regards, Tom.