From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Hutchings Subject: Re: Report Double Fetch Bug Found in Linux-4.6.1/kernel/auditsc.c Date: Tue, 21 Jun 2016 10:51:11 +0100 Message-ID: <1466502671.27155.185.camel@decadent.org.uk> References: <20160620182215.GC25615@madcap2.tricolour.ca> <20160620191814.GA2942@redhat.com> <480FAE99-E4E1-42D0-ABD5-8DC24A7EC9BB@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3092099196103419811==" Return-path: In-Reply-To: <480FAE99-E4E1-42D0-ABD5-8DC24A7EC9BB@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Pengfei Wang , Oleg Nesterov Cc: security@kernel.org, Richard Guy Briggs , "Krinke, Jens" , linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============3092099196103419811== Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-xrrqUaQc2a8qd7YSyL1a" --=-xrrqUaQc2a8qd7YSyL1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-06-21 at 10:37 +0100, Pengfei Wang wrote: > >=20 > > =E5=9C=A8 2016=E5=B9=B46=E6=9C=8820=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 8:18=EF=BC=8COleg Nesterov =E5=86=99=E9=81=93=EF=BC=9A > >=20 > > Not that I understand this report, but > >=20 > > On 06/20, Richard Guy Briggs wrote: > > >=20 > > > This function is only ever called by __audit_free(), which is only ev= er > > > called on failure of task creation or on exit of the task, so in neit= her > > > case can anything else change it. > >=20 > > How so? > >=20 > > Another thread or CLONE_VM task or /proc/pid/mem can change the user-sp= ace > > memory in parallel. > >=20 > > Oleg. >=20 >=20 > Exactly, by saying =E2=80=9Cchange the data=E2=80=9D, I mean the modifica= tion from > malicious users with crafted operations on the user space memory > directly, rather than the normal operations within the audit > subsystem in Linux. Moreover, since the copy operations from the user > space are not protected by any locks or synchronization primitives, > changing the data under race condition is feasible I think. Besides, > there isn=E2=80=99t any visible checking step in the code to guarantee th= e > consistency between the two copy operations. >=20 > Here I would like=C2=A0to figure out what the consequences really are onc= e > the data is changed between the two copy operations, such as changing > a none-control string to a control string but process it as a none- > control string that has no control chars. I think problems will > happen. So far as userland can see, kernel log lines are separated by newlines. If we fail to escape a newline, that makes it possible to inject arbitrary log lines into the kernel log, which may be misleading to the administrator or to software parsing the log. Ben. --=20 Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought. ... I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. - Maurice Wilkes, 1949 --=-xrrqUaQc2a8qd7YSyL1a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXaQ4PAAoJEOe/yOyVhhEJU24P+wYfBdUYymKEf86+6x7JM3sU FdBJeNJrQ9CPL5UAkpxwTOtCwfTcr2YCVwfA2cWKJcAV2a7pq7C5AAIlNYTglNQw cM3lCrseGcWiBgaKyf/GoBUGCctoq/YI2eTfIP1s3M561IZVZoj16pfn4/Ps5JmQ kd2BlJMbOEVPH7nxfJSC8YQ6ZP8J1KrmeFubOFiiiOPvw44eqw7d9Hk9k2L925C2 8nLie0tddgvOKosT00aY3A7tYKKfSKyYrFHtgBiq/bVXHbWf7Cgg6ESBSDSwnDmp qA+ETVna5Z5FCTo+ffVGn8xCPbs8vdErLFTAHZ+m6ibq/DGz0UUFAD1LHe2JGrpy V3kpbVGpd6wSZYIja/djuKwg9YeeAoTBua97ERaPO8aLQsa8v9kCmENXq5U09MZm od7CJrdZWz+K14MWgMjVQw/HxCNLxaedCzXTMEeXgUprB/d+dHEiZELYW6xv6tYL plRruPypNUolqzqJbc6umrrfgzYonok7ynS/YZyVtKoWf4F42Ywz/1PsRsDS2GLx z/13qS6HCXxJ0QYVdw1ps6Ikv2guPeNY6bHTIQ3iPLrZK0z9FON8Ju+La9AAwATZ q0sj4nE2CahtTIvHFiYssIHvQp1Na7ot+h4imdXUo/5tCbtg6NMpXbg26559dk9z AX7RvuP92B+UpoKIyaf7 =8KbV -----END PGP SIGNATURE----- --=-xrrqUaQc2a8qd7YSyL1a-- --===============3092099196103419811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3092099196103419811==--