[alsa-devel] [patch] [ALSA] sb16 - info leak in snd_sb_csp_ioctl()
There is a 2 byte hole after "info.func_nr" so we could leak unitialized stack information to userspace.
Fixes: 1da177e4c3f4 ('Linux-2.6.12-rc2') Signed-off-by: Dan Carpenter dan.carpenter@oracle.com
diff --git a/sound/isa/sb/sb16_csp.c b/sound/isa/sb/sb16_csp.c index c1aa21e..48da227 100644 --- a/sound/isa/sb/sb16_csp.c +++ b/sound/isa/sb/sb16_csp.c @@ -208,6 +208,7 @@ static int snd_sb_csp_ioctl(struct snd_hwdep * hw, struct file *file, unsigned i switch (cmd) { /* get information */ case SNDRV_SB_CSP_IOCTL_INFO: + memset(&info, 0, sizeof(info)); *info.codec_name = *p->codec_name; info.func_nr = p->func_nr; info.acc_format = p->acc_format;
At Thu, 7 Nov 2013 11:09:54 +0300, Dan Carpenter wrote:
There is a 2 byte hole after "info.func_nr" so we could leak unitialized stack information to userspace.
Fixes: 1da177e4c3f4 ('Linux-2.6.12-rc2')
Does this help at all? It means that the bug has been there even before moving to git. I think it's better to be removed for avoid confusion.
thanks,
Takashi
Signed-off-by: Dan Carpenter dan.carpenter@oracle.com
diff --git a/sound/isa/sb/sb16_csp.c b/sound/isa/sb/sb16_csp.c index c1aa21e..48da227 100644 --- a/sound/isa/sb/sb16_csp.c +++ b/sound/isa/sb/sb16_csp.c @@ -208,6 +208,7 @@ static int snd_sb_csp_ioctl(struct snd_hwdep * hw, struct file *file, unsigned i switch (cmd) { /* get information */ case SNDRV_SB_CSP_IOCTL_INFO:
memset(&info, 0, sizeof(info));
On Thu, Nov 07, 2013 at 09:48:08AM +0100, Takashi Iwai wrote:
At Thu, 7 Nov 2013 11:09:54 +0300, Dan Carpenter wrote:
There is a 2 byte hole after "info.func_nr" so we could leak unitialized stack information to userspace.
Fixes: 1da177e4c3f4 ('Linux-2.6.12-rc2')
Does this help at all? It means that the bug has been there even before moving to git. I think it's better to be removed for avoid confusion.
I think if you are back porting it then you know it goes back all the way. That seems useful.
The Fixes tag is still new so it's not totally clear what the rules are. I don't have strong feelings about this either way.
regards, dan carpenter
At Thu, 7 Nov 2013 12:09:47 +0300, Dan Carpenter wrote:
On Thu, Nov 07, 2013 at 09:48:08AM +0100, Takashi Iwai wrote:
At Thu, 7 Nov 2013 11:09:54 +0300, Dan Carpenter wrote:
There is a 2 byte hole after "info.func_nr" so we could leak unitialized stack information to userspace.
Fixes: 1da177e4c3f4 ('Linux-2.6.12-rc2')
Does this help at all? It means that the bug has been there even before moving to git. I think it's better to be removed for avoid confusion.
I think if you are back porting it then you know it goes back all the way. That seems useful.
Yeah, I understand the usefulness of the tag. But my understanding is that this is used for pointing a regression point. However, in this particular case, the commit you pointed there isn't the actual commit introducing the bug. It's the genesis commit containing everything.
The Fixes tag is still new so it's not totally clear what the rules are. I don't have strong feelings about this either way.
OK, then let me drop that tag in this case.
thanks,
Takashi
participants (2)
-
Dan Carpenter -
Takashi Iwai