lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 25 Jul 2006 01:42:19 -0700 (PDT)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Andrew Morton <akpm@...l.org>
cc:	Mauro Carvalho Chehab <mchehab@...radead.org>, robfitz@...k.net,
	Linux and Kernel Video <video4linux-list@...hat.com>,
	76306.1226@...puserve.com, fork0@...nline.de, greg@...ah.com,
	linux-kernel@...r.kernel.org, rdunlap@...otime.net,
	v4l-dvb maintainer list <v4l-dvb-maintainer@...uxtv.org>,
	shemminger@...l.org
Subject: Re: [v4l-dvb-maintainer] Re: [PATCH] V4L: struct video_device
 corruption

On Mon, 24 Jul 2006, Andrew Morton wrote:
> On Sat, 15 Jul 2006 22:31:04 -0300
> Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
>
> > Em Sáb, 2006-07-15 às 23:08 +0000, Robert Fitzsimons escreveu:
> > > The layout of struct video_device would change depending on whether
> > > videodev.h (V4L1) was include or not before v4l2-dev.h, which caused
> > > the structure to get corrupted.
> > Hmm... good point! However, I the proper solution would be to trust on
> > CONFIG_VIDEO_V4L1_COMPAT or CONFIG_VIDEO_V4L1 instead. it makes no sense
> > to keep a pointer to an unsupported callback, when V4L1 is not selected.
> >
>
> So I've lost the plot with all of this.  Does the current git-dvb contain
> the desired fixes?

The problem was that the v4l code in general was not using
CONFIG_VIDEO_V4L1* like it should, but was detecting V4L1 support based on
whether on not the V4L1 header file had been included.

Some drivers didn't depend on V4L1 in Kconfig, and would include the V4L1
header when V4L1 was off.  This caused some code to think V4L1 was off and
some code to think it was on.

This caused a serious bug with inconsistent defintions of struct
video_device, as well as other problems.

I posted a patch that fixed the video_device problem, then Mauro made a
comprehensive patch that incorporated this fix and well as all the other
code that was using V4L1 when it shouldn't.  That patch is in the v4l-dvb
Mercurial repository, but not moved on to git yet.

> Do we expect this will fix the various DVB crashes which people (including
> Alex) have reported?

This problem would only appear if VIDEO_V4L1 was turned off.  If it was on,
then all the code would agree it was on, and there would be no problems.
If the crash is still there when VIDEO_V4L1 = y, then it's not related to
this bug.

If VIDEO_V4L1 was turned off, then some drivers (one of which is bttv)
would have a different struct video_device than the video core code.  This
would break things so completely that it could crash just about anywhere.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ