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
| ||
|
Message-Id: <20220303022729.9321-1-xiam0nd.tong@gmail.com> Date: Thu, 3 Mar 2022 10:27:29 +0800 From: Xiaomeng Tong <xiam0nd.tong@...il.com> To: david.laight@...lab.com Cc: akpm@...ux-foundation.org, alsa-devel@...a-project.org, amd-gfx@...ts.freedesktop.org, andriy.shevchenko@...ux.intel.com, arnd@...db.de, bcm-kernel-feedback-list@...adcom.com, bjohannesmeyer@...il.com, c.giuffrida@...nl, christian.koenig@....com, christophe.jaillet@...adoo.fr, dan.carpenter@...cle.com, dmaengine@...r.kernel.org, drbd-dev@...ts.linbit.com, dri-devel@...ts.freedesktop.org, gustavo@...eddedor.com, h.j.bos@...nl, intel-gfx@...ts.freedesktop.org, intel-wired-lan@...ts.osuosl.org, jakobkoschel@...il.com, jgg@...pe.ca, keescook@...omium.org, kgdb-bugreport@...ts.sourceforge.net, kvm@...r.kernel.org, linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org, linux-block@...r.kernel.org, linux-cifs@...r.kernel.org, linux-crypto@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linux-mediatek@...ts.infradead.org, linux-pm@...r.kernel.org, linux-rdma@...r.kernel.org, linux-scsi@...r.kernel.org, linux-sgx@...r.kernel.org, linux-staging@...ts.linux.dev, linux-tegra@...r.kernel.org, linux-usb@...r.kernel.org, linux-wireless@...r.kernel.org, linux1394-devel@...ts.sourceforge.net, linux@...musvillemoes.dk, linuxppc-dev@...ts.ozlabs.org, nathan@...nel.org, netdev@...r.kernel.org, nouveau@...ts.freedesktop.org, rppt@...nel.org, samba-technical@...ts.samba.org, tglx@...utronix.de, tipc-discussion@...ts.sourceforge.net, torvalds@...ux-foundation.org, v9fs-developer@...ts.sourceforge.net, xiam0nd.tong@...il.com Subject: RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr On Wed, 2 Mar 2022 14:04:06 +0000, David Laight <David.Laight@...LAB.COM> wrote: > I think that it would be better to make any alternate loop macro > just set the variable to NULL on the loop exit. > That is easier to code for and the compiler might be persuaded to > not redo the test. No, that would lead to a NULL dereference. The problem is the mis-use of iterator outside the loop on exit, and the iterator will be the HEAD's container_of pointer which pointers to a type-confused struct. Sidenote: The *mis-use* here refers to mistakely access to other members of the struct, instead of the list_head member which acutally is the valid HEAD. IOW, you would dereference a (NULL + offset_of_member) address here. Please remind me if i missed something, thanks. > OTOH there may be alternative definitions that can be used to get > the compiler (or other compiler-like tools) to detect broken code. > Even if the definition can't possibly generate a working kerrnel. The "list_for_each_entry_inside(pos, type, head, member)" way makes the iterator invisiable outside the loop, and would be catched by compiler if use-after-loop things happened. Can you share your "alternative definitions" details? thanks! -- Xiaomeng Tong
Powered by blists - more mailing lists