Are the different values that Lynis found in my Kernel (expected vs. real) a result of hacker compromise, or because I am using an older kernel?

In the Kernel hardening report section of Lynis, I'm seeing the result:

Result: sysctl key kernel.kptr_restrict has a different value than expected in scan profile. Expected=2, Real=0

Doing a google search, I came across the following article:
https://lwn.net/Articles/420403

"If kptr_restrict is set to 0, no deviation from the standard %p behavior
occurs. If kptr_restrict is set to 1, if the current user (intended to
be a reader via seq_printf(), etc.) does not have CAP_SYSLOG (which is
currently in the LSM tree), kernel pointers using %pK are printed as
0's. If kptr_restrict is set to 2, kernel pointers using %pK are
printed as 0's regardless of privileges. Replacing with 0's was chosen
over the default "(null)", which cannot be parsed by userland %p, which
expects "(nil)".

v3 adds the "2" setting, cleans up documentation, removes the CONFIG,
and incorporates changes and suggestions from Andrew Morton.

v2 improves checking for inappropriate context, on suggestion by Peter
Zijlstra. Thanks to Thomas Graf for suggesting use of a centralized
format specifier."

My questions:

Are the different values that Lynis found in my Kernel (expected vs. real) a result of hacker compromise? Or rather because I'm using an older Centos 6.5 system instead of the lastest version of Centos? From the above article, it appears that the real value of "0" is standard default behaviour (although Lynis is expecting a newer more updated value of "2").

Is there a way I can manually set/change the values for the above items identified by Lynis? For example, how could I manually change the kernel.kptr value to "2" from the current "0"? How could I set the other Kernel values? Or does this require a Centos kernel/OS upgrade to a newer version of Centos?