On Thu 2020-10-01 00:39:31, Joe Perches wrote:
> On Thu, 2020-10-01 at 09:26 +0200, Petr Mladek wrote:
> > On Wed 2020-09-30 08:25:24, Joe Perches wrote:
> > > On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote:
> > > > If a reader provides a buffer that is smaller than the message text,
> > > >
On Thu, 2020-10-01 at 09:26 +0200, Petr Mladek wrote:
> On Wed 2020-09-30 08:25:24, Joe Perches wrote:
> > On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote:
> > > If a reader provides a buffer that is smaller than the message text,
> > > the @text_len field of @info will have a value larger tha
On Wed 2020-09-30 08:25:24, Joe Perches wrote:
> On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote:
> > If a reader provides a buffer that is smaller than the message text,
> > the @text_len field of @info will have a value larger than the buffer
> > size. If readers blindly read @text_len bytes
On (20/09/30 13:53), Petr Mladek wrote:
>
> Anyway, please do so in a followup patch. I would like to push this
> patchset into linux-next ASAP so that the robots could continue
> finding new bugs.
ACK.
-ss
On Wed, 2020-09-30 at 11:07 +0206, John Ogness wrote:
> If a reader provides a buffer that is smaller than the message text,
> the @text_len field of @info will have a value larger than the buffer
> size. If readers blindly read @text_len bytes of data without
> checking the size, they will read be
On Wed 2020-09-30 11:07:33, John Ogness wrote:
> If a reader provides a buffer that is smaller than the message text,
> the @text_len field of @info will have a value larger than the buffer
> size. If readers blindly read @text_len bytes of data without
> checking the size, they will read beyond th
On Wed 2020-09-30 13:48:56, John Ogness wrote:
> On 2020-09-30, Petr Mladek wrote:
> > Anyway, I see hardcoded limit more like a hack. It limits something
> > somewhere so that some other code somewhere else is safe to use.
> >
> > And printk.c is really bad from this point. It sometimes does not
On 2020-09-30, Petr Mladek wrote:
> Anyway, I see hardcoded limit more like a hack. It limits something
> somewhere so that some other code somewhere else is safe to use.
>
> And printk.c is really bad from this point. It sometimes does not
> check for overflow because it "knows" that the buffers
On Wed 2020-09-30 12:30:50, John Ogness wrote:
> On 2020-09-30, Sergey Senozhatsky wrote:
> > On (20/09/30 11:07), John Ogness wrote:
> >> bool prb_reserve_in_last(struct prb_reserved_entry *e, struct
> >> printk_ringbuffer *rb,
> >> - struct printk_record *r, u32 caller_id);
>
On 2020-09-30, Sergey Senozhatsky wrote:
> On (20/09/30 11:07), John Ogness wrote:
>> bool prb_reserve_in_last(struct prb_reserved_entry *e, struct
>> printk_ringbuffer *rb,
>> - struct printk_record *r, u32 caller_id);
>> + struct printk_record *r, u32 ca
On (20/09/30 11:07), John Ogness wrote:
[..]
> @@ -1389,6 +1391,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
> struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf
If a reader provides a buffer that is smaller than the message text,
the @text_len field of @info will have a value larger than the buffer
size. If readers blindly read @text_len bytes of data without
checking the size, they will read beyond their buffer.
Add this check to record_print_text() to p
12 matches
Mail list logo
