Justin Stitt writes:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect partition_name to be NUL-terminated based on its usage with
> format strings:
> | dev_info(hostdat
On Mon, Nov 20 2023 at 19:34, Vlastimil Babka wrote:
> The CPUHP_SLAB_PREPARE hooks are only used by SLAB which is removed.
> SLUB defines them as NULL, so we can remove those altogether.
>
> Signed-off-by: Vlastimil Babka
Acked-by: Thomas Gleixner
Kees Cook writes:
> On Thu, Oct 19, 2023 at 05:44:59PM +, Justin Stitt wrote:
>> strncpy() is deprecated for use on NUL-terminated destination strings
>> [1] and as such we should prefer more robust and less ambiguous string
>> interfaces.
>>
>> Based on the deliberate `sizeof(dest) ... - 1`
Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> Based on the deliberate `sizeof(dest) ... - 1` pattern we can see that
> both dump_info->dev_human_readable and d
Hey Thomas.
Thx for the clarifications. I did more of a deep dive into your set and
have additional comments (in line). I think const-ing all this is a good
approach. The way forward is to be able to see the entire patch set of
changes in a V1 or a shared repo somewhere to have a better picture of
On Thu, Nov 30, 2023 at 05:25:20PM -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 12:01:01 -0800 Kees Cook wrote:
> > This has the additional benefit of being defensive in the face of nlattr
> > corruption or logic errors (i.e. nla_len being set smaller than
> > NLA_HDRLEN).
>
> As Johannes pr
On Thu, Nov 30, 2023 at 10:40:21PM -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 13:59:58 -0800 Kees Cook wrote:
> > Applied to for-next/hardening, thanks!
> >
> > [1/1] net: dsa: lan9303: use ethtool_sprintf() for lan9303_get_strings()
> > https://git.kernel.org/kees/c/f1c7720549bf
>
On Thu, Nov 30, 2023 at 10:41:34PM -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 13:59:48 -0800 Kees Cook wrote:
> > [1/1] net: ena: replace deprecated strncpy with strscpy
> > https://git.kernel.org/kees/c/111f5a435d33
>
> Again, please drop, Arthur requested for the commit message
> t
On Thu, Nov 30, 2023 at 10:43:12PM -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 14:00:28 -0800 Kees Cook wrote:
> > [1/1] qlcnic: replace deprecated strncpy with strscpy
> > https://git.kernel.org/kees/c/f8bef1ef8095
>
> You asked for changes yourself here, please drop all the networki
On Thu, Nov 30, 2023 at 10:43:34PM -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 14:00:33 -0800 Kees Cook wrote:
> > Applied to for-next/hardening, thanks!
> >
> > [1/1] net: mdio: replace deprecated strncpy with strscpy
> > https://git.kernel.org/kees/c/3247bb945786
>
> newer version
On Fri, Dec 01, 2023 at 03:27:26PM +0900, Masami Hiramatsu wrote:
> On Thu, 30 Nov 2023 12:56:08 -0800
> Kees Cook wrote:
>
> > strlcpy() reads the entire source buffer first. This read may exceed
> > the destination size limit. This is both inefficient and can lead
> > to linear read overflows i
On Thu, 30 Nov 2023 12:56:08 -0800, Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the size
On Fri, 1 Dec 2023 10:17:02 -0800 Kees Cook wrote:
> > > -static inline int nla_len(const struct nlattr *nla)
> > > +static inline u16 nla_len(const struct nlattr *nla)
> > > {
> > > - return nla->nla_len - NLA_HDRLEN;
> > > + return nla->nla_len > NLA_HDRLEN ? nla->nla_len - NLA_HDRLEN : 0;
> > >
On Fri, Dec 01, 2023 at 10:45:05AM -0800, Jakub Kicinski wrote:
> On Fri, 1 Dec 2023 10:17:02 -0800 Kees Cook wrote:
> > > > -static inline int nla_len(const struct nlattr *nla)
> > > > +static inline u16 nla_len(const struct nlattr *nla)
> > > > {
> > > > - return nla->nla_len - NLA_HDRLEN;
On Fri, 1 Dec 2023 20:39:44 -0800 Kees Cook wrote:
> > We are reading nla->nla_len, which is the first 2 bytes of the structure.
> > And then we check if the structure is... there?
>
> I'm not debating whether it's there or not -- I'm saying the _contents_ of
> "nlattr::nla_len", in the face of
15 matches
Mail list logo