Bug 57791 - NULL pointer dereference bug after upgrading to systemd-203
Summary: NULL pointer dereference bug after upgrading to systemd-203
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Casey Schaufler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-08 14:32 UTC by Ivan Bulatovic
Modified: 2013-08-21 00:36 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.9.0
Tree: Mainline
Regression: No


Attachments
linux-3.9.0 kernel config (83.81 KB, text/plain)
2013-05-08 14:32 UTC, Ivan Bulatovic
Details
Image of the panic (258.54 KB, image/jpeg)
2013-05-08 14:33 UTC, Ivan Bulatovic
Details

Description Ivan Bulatovic 2013-05-08 14:32:01 UTC
Created attachment 100971 [details]
linux-3.9.0 kernel config

After updating Arch Linux with custom 3.9.0 kernel from systemd-202 to systemd-203 I get the following:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000018

At first all I've got was drm_warn_on_modeset_not_all_locked warning but as described here:

http://lists.freedesktop.org/archives/dri-devel/2013-May/038154.html

when I've compiled the kernel with this patch:

http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=a9b054e8ab06504c2afa0e307ee78d3778993a1d

I get the real reason for the panic (picture attached).

I've reported this on the freedesktop bugzilla here:

https://bugs.freedesktop.org/show_bug.cgi?id=64339

Lennart had his point of view on this one, so in the lack of evidence otherwise I had to report it here.

Contents of the /etc/fstab:

UUID=992352a9-7eaf-4cc4-bc3c-d3b1de96b279       /               ext4            rw,noatime,discard,data=ordered 0 1
UUID=643C40B93C4087CE   /storage        ntfs-3g defaults,uid=combuster,gid=users,dmask=027,fmask=137    0 0

I'll attach the .config for the kernel and an image of the panic.

Please move this to the appropriate section, I haven't had a clue where to report this one.

Thanks!
Comment 1 Ivan Bulatovic 2013-05-08 14:33:08 UTC
Created attachment 100981 [details]
Image of the panic
Comment 2 Casey Schaufler 2013-05-09 21:29:05 UTC
This appears to have crept in with the cgroups xattr support. It looks as if the dentry may not be complete when passed to Smack.
Comment 3 Casey Schaufler 2013-05-09 22:34:01 UTC
__d_xattr() references dentry->d_inode->i_mode, however d_inode is not set when d_instantiate() is called. When Smack goes looking to see if there are attributes associated with the dentry we get a NULL pointer reference. SELinux does not see this problem because cgroups are mounted without xattr based labeling enabled.

The quick and dirty fix is to add a check:

        if (dp->d_inode == NULL)
                return NULL;

prior to the buffer allocation in smk_fetch() in security/smack/smack_lsm.c

This won't solve the problem for SELinux with xattr based labeling enabled, but I suspect that if they wanted to run in that mode they's already be doing so.
Comment 4 Casey Schaufler 2013-05-10 22:41:20 UTC
This patch seems to fix the problem. It was tested by Ivan Bulatovic. I would prefer that the cgroup xattr code get fixed so that it initializes the dentry prior to calling d_instantiate, but this should do for now.


---
 security/smack/smack_lsm.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index d52c780..2ceafae 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -59,7 +59,8 @@ static char *smk_fetch(const char *name, struct inode *ip, struct dentry *dp)
 	char *buffer;
 	char *result = NULL;
 
-	if (ip->i_op->getxattr == NULL)
+	if (ip->i_op->getxattr == NULL || dp->d_inode == NULL ||
+	    dp->d_fsdata == NULL)
 		return NULL;
 
 	buffer = kzalloc(SMK_LONGLABEL, GFP_KERNEL);
Comment 5 Casey Schaufler 2013-08-21 00:36:27 UTC
Do not use the patch above. The commit: cgroup: initialize xattr before calling d_instantiate() d6cbf35dac8a3dadb9103379820c96d7c85df3d9 fixes the real problem.

Note You need to log in before you can comment on or make changes to this bug.