On Wed, Apr 17, 2019 at 3:02 PM Andrew Morton akpm@linux-foundation.org wrote:
On Wed, 17 Apr 2019 11:39:52 -0700 Dan Williams dan.j.williams@intel.com wrote:
At namespace creation time there is the potential for the "expected to be zero" fields of a 'pfn' info-block to be filled with indeterminate data. While the kernel buffer is zeroed on allocation it is immediately overwritten by nd_pfn_validate() filling it with the current contents of the on-media info-block location. For fields like, 'flags' and the 'padding' it potentially means that future implementations can not rely on those fields being zero.
In preparation to stop using the 'start_pad' and 'end_trunc' fields for section alignment, arrange for fields that are not explicitly initialized to be guaranteed zero. Bump the minor version to indicate it is safe to assume the 'padding' and 'flags' are zero. Otherwise, this corruption is expected to benign since all other critical fields are explicitly initialized.
Fixes: 32ab0a3f5170 ("libnvdimm, pmem: 'struct page' for pmem") Cc: stable@vger.kernel.org Signed-off-by: Dan Williams dan.j.williams@intel.com
Buried at the end of a 12 patch series. Should this be a standalone patch, suitable for a prompt merge?
It's not a problem unless a kernel implementation is explicitly expecting those fields to be zero-initialized. I only marked it for -stable in case some future kernel backports patch12. Otherwise it's benign on older kernels that don't have patch12 since all fields are indeed initialized.