Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu, Sep 13, 2018 at 8:55 AM peter enderborg wrote: > On 09/13/2018 01:11 PM, Michal Hocko wrote: > > On Thu 13-09-18 09:12:04, peter enderborg wrote: > >> On 09/13/2018 08:26 AM, Tetsuo Handa wrote: > >>> On 2018/09/13 12:02, Paul Moore wrote: > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > wrote: > > syzbot is hitting warning at str_read() [1] because len parameter can > > become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > > this case. > > > > [1] > > https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > > > > Signed-off-by: Tetsuo Handa > > Reported-by: syzbot > > > > --- > > security/selinux/ss/policydb.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/security/selinux/ss/policydb.c > > b/security/selinux/ss/policydb.c > > index e9394e7..f4eadd3 100644 > > --- a/security/selinux/ss/policydb.c > > +++ b/security/selinux/ss/policydb.c > > @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, > > void *fp, u32 len) > > if ((len == 0) || (len == (u32)-1)) > > return -EINVAL; > > > > - str = kmalloc(len + 1, flags); > > + str = kmalloc(len + 1, flags | __GFP_NOWARN); > > if (!str) > > return -ENOMEM; > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations? > > >>> Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return > >>> ZERO_SIZE_PTR) due to (len == (u32)-1) check above. > >>> > >>> The only concern would be whether you want allocation failure messages. > >>> I assumed you don't need it because we are returning -ENOMEM to the > >>> caller. > >>> > >> Would it not be better with > >> > >> char *str; > >> > >> if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) > >> return -EINVAL; > >> > >> str = kmalloc(len + 1, flags); > >> if (!str) > >> return -ENOMEM; > > I strongly suspect that you want kvmalloc rather than kmalloc here. The > > larger the request the more likely is the allocation to fail. > > > > I am not familiar with the code but I assume this is a root only > > interface so we don't have to worry about nasty users scenario. > > > I don't think we get any big data there at all. Usually less than 32 bytes. > However this data can be in fast path so a vmalloc is not an option. > > And some of the calls are GFP_ATOMC. Based on all the comments it looks like Tetsuo's original patch is probably the best fix right now. I'm going to merge this into selinux/next. Tetsuo, thanks for the patch, and thanks to everyone else for the comments/review. -- paul moore www.paul-moore.com ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu, Sep 13, 2018 at 3:12 AM peter enderborg wrote: > On 09/13/2018 08:26 AM, Tetsuo Handa wrote: > > On 2018/09/13 12:02, Paul Moore wrote: > >> On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > >> wrote: > >>> syzbot is hitting warning at str_read() [1] because len parameter can > >>> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > >>> this case. > >>> > >>> [1] > >>> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > >>> > >>> Signed-off-by: Tetsuo Handa > >>> Reported-by: syzbot > >>> > >>> --- > >>> security/selinux/ss/policydb.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/security/selinux/ss/policydb.c > >>> b/security/selinux/ss/policydb.c > >>> index e9394e7..f4eadd3 100644 > >>> --- a/security/selinux/ss/policydb.c > >>> +++ b/security/selinux/ss/policydb.c > >>> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void > >>> *fp, u32 len) > >>> if ((len == 0) || (len == (u32)-1)) > >>> return -EINVAL; > >>> > >>> - str = kmalloc(len + 1, flags); > >>> + str = kmalloc(len + 1, flags | __GFP_NOWARN); > >>> if (!str) > >>> return -ENOMEM; > >> Thanks for the patch. > >> > >> My eyes are starting to glaze over a bit chasing down all of the > >> different kmalloc() code paths trying to ensure that this always does > >> the right thing based on size of the allocation and the different slab > >> allocators ... are we sure that this will always return NULL when (len > >> + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > >> configurations? > >> > > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return > > ZERO_SIZE_PTR) due to (len == (u32)-1) check above. > > > > The only concern would be whether you want allocation failure messages. > > I assumed you don't need it because we are returning -ENOMEM to the caller. > > > Would it not be better with > > char *str; > > if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) > return -EINVAL; > > str = kmalloc(len + 1, flags); > if (!str) > return -ENOMEM; As long as it's safe, I'd rather leave the maximum allocation limit as a kmalloc internal and let kmalloc return NULL if we try too large of an allocation. -- paul moore www.paul-moore.com ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu, Sep 13, 2018 at 2:26 AM Tetsuo Handa wrote: > On 2018/09/13 12:02, Paul Moore wrote: > > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > > wrote: > >> syzbot is hitting warning at str_read() [1] because len parameter can > >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > >> this case. > >> > >> [1] > >> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > >> > >> Signed-off-by: Tetsuo Handa > >> Reported-by: syzbot > >> --- > >> security/selinux/ss/policydb.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/security/selinux/ss/policydb.c > >> b/security/selinux/ss/policydb.c > >> index e9394e7..f4eadd3 100644 > >> --- a/security/selinux/ss/policydb.c > >> +++ b/security/selinux/ss/policydb.c > >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void > >> *fp, u32 len) > >> if ((len == 0) || (len == (u32)-1)) > >> return -EINVAL; > >> > >> - str = kmalloc(len + 1, flags); > >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); > >> if (!str) > >> return -ENOMEM; > > > > Thanks for the patch. > > > > My eyes are starting to glaze over a bit chasing down all of the > > different kmalloc() code paths trying to ensure that this always does > > the right thing based on size of the allocation and the different slab > > allocators ... are we sure that this will always return NULL when (len > > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > > configurations? > > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return > ZERO_SIZE_PTR) due to (len == (u32)-1) check above. > > The only concern would be whether you want allocation failure messages. > I assumed you don't need it because we are returning -ENOMEM to the caller. I'm not to worried about the failure messages, returning -ENOMEM should be sufficient in this case. -- paul moore www.paul-moore.com ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu, Sep 13, 2018 at 2:55 PM, peter enderborg wrote: >> syzbot is hitting warning at str_read() [1] because len parameter can >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >> this case. >> >> [1] >> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >> >> Signed-off-by: Tetsuo Handa >> Reported-by: syzbot >> >> --- >> security/selinux/ss/policydb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/security/selinux/ss/policydb.c >> b/security/selinux/ss/policydb.c >> index e9394e7..f4eadd3 100644 >> --- a/security/selinux/ss/policydb.c >> +++ b/security/selinux/ss/policydb.c >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void >> *fp, u32 len) >> if ((len == 0) || (len == (u32)-1)) >> return -EINVAL; >> >> - str = kmalloc(len + 1, flags); >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >> if (!str) >> return -ENOMEM; > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations? > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return ZERO_SIZE_PTR) due to (len == (u32)-1) check above. The only concern would be whether you want allocation failure messages. I assumed you don't need it because we are returning -ENOMEM to the caller. >>> Would it not be better with >>> >>> char *str; >>> >>> if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) >>> return -EINVAL; >>> >>> str = kmalloc(len + 1, flags); >>> if (!str) >>> return -ENOMEM; >> I strongly suspect that you want kvmalloc rather than kmalloc here. The >> larger the request the more likely is the allocation to fail. >> >> I am not familiar with the code but I assume this is a root only >> interface so we don't have to worry about nasty users scenario. >> > I don't think we get any big data there at all. Usually less than 32 bytes. > However this data can be in fast path so a vmalloc is not an option. > > And some of the calls are GFP_ATOMC. Then another option is to introduce reasonable application-specific limit and not rely on kmalloc-anything at all. We did this for some instances of this warning too. One advantage of it is that it prevents users from doing silly things (or maybe will discover bugs in user-space code better, why are they asking for megs here?). Another advantage is that what works on one version of kernel will continue to work on another version of kernel. Today it's possible that a policy works on one kernel with 4MB kmalloc limit, but breaks on another with 2MB limit. Ideally exact value of KMALLOC_MAX_SIZE does not affect anything in user-space. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On 09/13/2018 01:11 PM, Michal Hocko wrote: > On Thu 13-09-18 09:12:04, peter enderborg wrote: >> On 09/13/2018 08:26 AM, Tetsuo Handa wrote: >>> On 2018/09/13 12:02, Paul Moore wrote: On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa wrote: > syzbot is hitting warning at str_read() [1] because len parameter can > become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > this case. > > [1] > https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > > Signed-off-by: Tetsuo Handa > Reported-by: syzbot > > --- > security/selinux/ss/policydb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/selinux/ss/policydb.c > b/security/selinux/ss/policydb.c > index e9394e7..f4eadd3 100644 > --- a/security/selinux/ss/policydb.c > +++ b/security/selinux/ss/policydb.c > @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void > *fp, u32 len) > if ((len == 0) || (len == (u32)-1)) > return -EINVAL; > > - str = kmalloc(len + 1, flags); > + str = kmalloc(len + 1, flags | __GFP_NOWARN); > if (!str) > return -ENOMEM; Thanks for the patch. My eyes are starting to glaze over a bit chasing down all of the different kmalloc() code paths trying to ensure that this always does the right thing based on size of the allocation and the different slab allocators ... are we sure that this will always return NULL when (len + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator configurations? >>> Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return >>> ZERO_SIZE_PTR) due to (len == (u32)-1) check above. >>> >>> The only concern would be whether you want allocation failure messages. >>> I assumed you don't need it because we are returning -ENOMEM to the caller. >>> >> Would it not be better with >> >> char *str; >> >> if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) >> return -EINVAL; >> >> str = kmalloc(len + 1, flags); >> if (!str) >> return -ENOMEM; > I strongly suspect that you want kvmalloc rather than kmalloc here. The > larger the request the more likely is the allocation to fail. > > I am not familiar with the code but I assume this is a root only > interface so we don't have to worry about nasty users scenario. > I don't think we get any big data there at all. Usually less than 32 bytes. However this data can be in fast path so a vmalloc is not an option. And some of the calls are GFP_ATOMC. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu 13-09-18 09:12:04, peter enderborg wrote: > On 09/13/2018 08:26 AM, Tetsuo Handa wrote: > > On 2018/09/13 12:02, Paul Moore wrote: > >> On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > >> wrote: > >>> syzbot is hitting warning at str_read() [1] because len parameter can > >>> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > >>> this case. > >>> > >>> [1] > >>> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > >>> > >>> Signed-off-by: Tetsuo Handa > >>> Reported-by: syzbot > >>> > >>> --- > >>> security/selinux/ss/policydb.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/security/selinux/ss/policydb.c > >>> b/security/selinux/ss/policydb.c > >>> index e9394e7..f4eadd3 100644 > >>> --- a/security/selinux/ss/policydb.c > >>> +++ b/security/selinux/ss/policydb.c > >>> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void > >>> *fp, u32 len) > >>> if ((len == 0) || (len == (u32)-1)) > >>> return -EINVAL; > >>> > >>> - str = kmalloc(len + 1, flags); > >>> + str = kmalloc(len + 1, flags | __GFP_NOWARN); > >>> if (!str) > >>> return -ENOMEM; > >> Thanks for the patch. > >> > >> My eyes are starting to glaze over a bit chasing down all of the > >> different kmalloc() code paths trying to ensure that this always does > >> the right thing based on size of the allocation and the different slab > >> allocators ... are we sure that this will always return NULL when (len > >> + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > >> configurations? > >> > > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return > > ZERO_SIZE_PTR) due to (len == (u32)-1) check above. > > > > The only concern would be whether you want allocation failure messages. > > I assumed you don't need it because we are returning -ENOMEM to the caller. > > > Would it not be better with > > char *str; > > if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) > return -EINVAL; > > str = kmalloc(len + 1, flags); > if (!str) > return -ENOMEM; I strongly suspect that you want kvmalloc rather than kmalloc here. The larger the request the more likely is the allocation to fail. I am not familiar with the code but I assume this is a root only interface so we don't have to worry about nasty users scenario. -- Michal Hocko SUSE Labs ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Thu, Sep 13, 2018 at 5:02 AM, Paul Moore wrote: > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > wrote: >> syzbot is hitting warning at str_read() [1] because len parameter can >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >> this case. >> >> [1] >> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >> >> Signed-off-by: Tetsuo Handa >> Reported-by: syzbot >> --- >> security/selinux/ss/policydb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c >> index e9394e7..f4eadd3 100644 >> --- a/security/selinux/ss/policydb.c >> +++ b/security/selinux/ss/policydb.c >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void >> *fp, u32 len) >> if ((len == 0) || (len == (u32)-1)) >> return -EINVAL; >> >> - str = kmalloc(len + 1, flags); >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >> if (!str) >> return -ENOMEM; > > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations? Yes, it's the blessed way to do it. We have lots of similar cases: https://elixir.bootlin.com/linux/v4.19-rc3/ident/__GFP_NOWARN ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On 2018/09/13 12:02, Paul Moore wrote: > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > wrote: >> syzbot is hitting warning at str_read() [1] because len parameter can >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >> this case. >> >> [1] >> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >> >> Signed-off-by: Tetsuo Handa >> Reported-by: syzbot >> --- >> security/selinux/ss/policydb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c >> index e9394e7..f4eadd3 100644 >> --- a/security/selinux/ss/policydb.c >> +++ b/security/selinux/ss/policydb.c >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void >> *fp, u32 len) >> if ((len == 0) || (len == (u32)-1)) >> return -EINVAL; >> >> - str = kmalloc(len + 1, flags); >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >> if (!str) >> return -ENOMEM; > > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations? > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return ZERO_SIZE_PTR) due to (len == (u32)-1) check above. The only concern would be whether you want allocation failure messages. I assumed you don't need it because we are returning -ENOMEM to the caller. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On 09/13/2018 08:26 AM, Tetsuo Handa wrote: > On 2018/09/13 12:02, Paul Moore wrote: >> On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa >> wrote: >>> syzbot is hitting warning at str_read() [1] because len parameter can >>> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >>> this case. >>> >>> [1] >>> https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >>> >>> Signed-off-by: Tetsuo Handa >>> Reported-by: syzbot >>> --- >>> security/selinux/ss/policydb.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c >>> index e9394e7..f4eadd3 100644 >>> --- a/security/selinux/ss/policydb.c >>> +++ b/security/selinux/ss/policydb.c >>> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void >>> *fp, u32 len) >>> if ((len == 0) || (len == (u32)-1)) >>> return -EINVAL; >>> >>> - str = kmalloc(len + 1, flags); >>> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >>> if (!str) >>> return -ENOMEM; >> Thanks for the patch. >> >> My eyes are starting to glaze over a bit chasing down all of the >> different kmalloc() code paths trying to ensure that this always does >> the right thing based on size of the allocation and the different slab >> allocators ... are we sure that this will always return NULL when (len >> + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator >> configurations? >> > Yes, for (len + 1) cannot become 0 (which causes kmalloc() to return > ZERO_SIZE_PTR) due to (len == (u32)-1) check above. > > The only concern would be whether you want allocation failure messages. > I assumed you don't need it because we are returning -ENOMEM to the caller. > Would it not be better with char *str; if ((len == 0) || (len == (u32)-1) || (len >= KMALLOC_MAX_SIZE)) return -EINVAL; str = kmalloc(len + 1, flags); if (!str) return -ENOMEM; ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa wrote: > syzbot is hitting warning at str_read() [1] because len parameter can > become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for > this case. > > [1] > https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 > > Signed-off-by: Tetsuo Handa > Reported-by: syzbot > --- > security/selinux/ss/policydb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c > index e9394e7..f4eadd3 100644 > --- a/security/selinux/ss/policydb.c > +++ b/security/selinux/ss/policydb.c > @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void *fp, > u32 len) > if ((len == 0) || (len == (u32)-1)) > return -EINVAL; > > - str = kmalloc(len + 1, flags); > + str = kmalloc(len + 1, flags | __GFP_NOWARN); > if (!str) > return -ENOMEM; Thanks for the patch. My eyes are starting to glaze over a bit chasing down all of the different kmalloc() code paths trying to ensure that this always does the right thing based on size of the allocation and the different slab allocators ... are we sure that this will always return NULL when (len + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator configurations? -- paul moore www.paul-moore.com ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[PATCH] selinux: Add __GFP_NOWARN to allocation at str_read()
syzbot is hitting warning at str_read() [1] because len parameter can become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for this case. [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 Signed-off-by: Tetsuo Handa Reported-by: syzbot --- security/selinux/ss/policydb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index e9394e7..f4eadd3 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void *fp, u32 len) if ((len == 0) || (len == (u32)-1)) return -EINVAL; - str = kmalloc(len + 1, flags); + str = kmalloc(len + 1, flags | __GFP_NOWARN); if (!str) return -ENOMEM; -- 1.8.3.1 ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
