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
| ||
|
Date: Fri, 21 Apr 2017 06:36:19 -0400 From: Jamal Hadi Salim <jhs@...atatu.com> To: David Miller <davem@...emloft.net> Cc: eric.dumazet@...il.com, jiri@...nulli.us, netdev@...r.kernel.org, xiyou.wangcong@...il.com Subject: Re: [PATCH net-next v4 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch On 17-04-20 01:58 PM, David Miller wrote: > From: Jamal Hadi Salim <jhs@...atatu.com> > Date: Thu, 20 Apr 2017 13:38:14 -0400 > >> There are no examples of such issues with bitmasks encapsulated in >> TLVs >> It does not make much sense to have a TLV for each of these >> bits when i can fit a bunch of them in u16/32/64. > > I have not ruled out bitmasks. I'm only saying that the kernel must > properly reject bits it doesn't recognize when they are set. > It is the other way round from what i see: It ignores them. This allows new bits to be added over time. Note: It is a bug - which must be fixed - if user space sets something the kernel doesnt want it to set. Even then, the only good use case i can think of for something like this is the kernel is exposing something to user space for read-only and user space is being silly and setting read-only bits on requests to the kernel. But even that is not a catastrophic issue; kernel should just ignore it. > Each bit must have a strict semantic, even unused ones, otherwise > unused ones may never safely be used in the future. > I think we are pretty good at this. It would be interesting to have a fuzzer which sets random bits on a TLV bitmask and see what bugs show up. cheers, jamal
Powered by blists - more mailing lists