On Thu, 2024-05-16 at 20:23 -0400, Kenton Groombridge wrote:
> req->n_channels must be set before req->channels[] can be used.
> Additionally, memory addresses after the "channels" array need to be
> calculated from the allocation base ("request") instead of the first
> "out of bounds" index of "ch
On Thu, 2024-05-16 at 12:20 -0700, Kees Cook wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On Thu, May 16, 2024 at 03:28:16PM +, Manthey, Norbert wro
On Fri, May 17, 2024 at 02:26:47AM +0100, Al Viro wrote:
> On Fri, May 17, 2024 at 02:13:22AM +0100, Matthew Wilcox wrote:
> > On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> > > When running syzkaller with the newly reintroduced signed integer
> > > overflow sanitizer we encounter
On Fri, May 17, 2024 at 02:13:22AM +0100, Matthew Wilcox wrote:
> On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> > When running syzkaller with the newly reintroduced signed integer
> > overflow sanitizer we encounter this report:
>
> why do you keep saying it's unintentional? it'
On Fri, May 17, 2024 at 12:29:06AM +, Justin Stitt wrote:
> When running syzkaller with the newly reintroduced signed integer
> overflow sanitizer we encounter this report:
why do you keep saying it's unintentional? it's clearly intended.
Using syzkaller with the recently reintroduced signed integer overflow
sanitizer produces this UBSAN report:
UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:738:18
9223372036854775806 + 4 cannot be represented in type 'long'
Call Trace:
dump_stack_lvl+0x93/0xd0
handle_overflow+0x171/0x1
When running syzkaller with the newly reintroduced signed integer
overflow sanitizer we encounter this report:
UBSAN: signed-integer-overflow in ../fs/read_write.c:91:10
9223372036854775807 + 4096 cannot be represented in type 'loff_t' (aka 'long
long')
Call Trace:
dump_stack_lvl+0x93/0xd0
ha
req->n_channels must be set before req->channels[] can be used.
Additionally, memory addresses after the "channels" array need to be
calculated from the allocation base ("request") instead of the first
"out of bounds" index of "channels" to avoid a runtime bounds check
warning.
This patch is large
On Thu, May 16, 2024 at 4:40 PM Justin Stitt wrote:
> Isn't this usually supplied from the user and can be some pretty
> random stuff? Are you suggesting we update
> timekeeping_validate_timex() to include a check to limit the maxerror
> field to (NTP_PHASE_LIMIT-(MAXFREQ / NSEC_PER_USEC))? It see
Hi,
On Tue, May 14, 2024 at 3:38 AM Thomas Gleixner wrote:
>
> On Tue, May 07 2024 at 04:34, Justin Stitt wrote:
> > Using syzkaller alongside the newly reintroduced signed integer overflow
> > sanitizer spits out this report:
> >
> > [ 138.454979] [ cut here ]
> > [ 138
On Thu, May 16, 2024 at 12:48:47PM -0700, Justin Stitt wrote:
>
> It is incredibly important that the exact opposite approach is taken;
> we need to be annotating (or adding type qualifiers to) the _expected_
> overflow cases. The omniscience required to go and properly annotate
> all the spots th
On Thu, May 16, 2024 at 12:48:47PM -0700, Justin Stitt wrote:
> I don't think we're capable of identifying every single problematic
> overflow/wraparound case in the kernel, this is pretty obvious
> considering we've had decades to do so. Instead, it seems much more
> feasible that we annotate (ver
Hi,
On Thu, May 16, 2024 at 7:09 AM Peter Zijlstra wrote:
>
> On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
> >
> > I am a broken record. :) This is _not_ about undefined behavior.
>
> And yet you introduced CONFIG_UBSAN_SIGNED_WRAP... *UB*san, get it?
We should think of UBSAN as an
On Thu, May 16, 2024 at 03:28:16PM +, Manthey, Norbert wrote:
> we published an extension for the Coverity model that is used by the
> CoverityScan setup for the Linux kernel [1]. We have been using this
> extension to analyze the 6.1 kernel branch, and reported some fixes to
> the upstream cod
On Thu, May 16, 2024 at 05:25:58PM +0200, Amelie Delaunay wrote:
> On 5/15/24 20:56, Frank Li wrote:
> > On Tue, Apr 23, 2024 at 02:32:55PM +0200, Amelie Delaunay wrote:
> > > STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
> > > controller:
...
> > > + writel_relaxed(hwd
On Thu, May 16, 2024 at 03:28:16PM +, Manthey, Norbert wrote:
> Dear Kees, all,
>
> we published an extension for the Coverity model that is used by the
> CoverityScan setup for the Linux kernel [1]. We have been using this
> extension to analyze the 6.1 kernel branch, and reported some fixes
Dear Kees, all,
we published an extension for the Coverity model that is used by the
CoverityScan setup for the Linux kernel [1]. We have been using this
extension to analyze the 6.1 kernel branch, and reported some fixes to
the upstream code base that are based on this model [2]. Feel free to
mer
On 5/15/24 20:56, Frank Li wrote:
On Tue, Apr 23, 2024 at 02:32:55PM +0200, Amelie Delaunay wrote:
STM32 DMA3 driver supports the 3 hardware configurations of the STM32 DMA3
controller:
- LPDMA (Low Power): 4 channels, no FIFO
- GPDMA (General Purpose): 16 channels, FIFO from 8 to 32 bytes
- HPD
On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
>
>
> On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra wrote:
> >On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> >> For example, the most common case of overflow we've ever had has very
> >> much been array indexing. Now
On Tue May 14, 2024 at 12:23 PM UTC, Mickaël Salaün wrote:
> > Development happens
> > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next
> > branch, but I'd advice against looking into it until we add some order
> > to the rework. Regardless, feel free to get in touch.
>
> Than
On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra wrote:
>On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
>> For example, the most common case of overflow we've ever had has very
>> much been array indexing. Now, sometimes that has actually been actual
>> undefined behavior, becau
On 5/15/24 20:45, Frank Li wrote:
On Mon, May 13, 2024 at 11:21:18AM +0200, Amelie Delaunay wrote:
Hi Frank,
On 5/7/24 22:26, Frank Li wrote:
On Tue, May 07, 2024 at 01:33:31PM +0200, Amelie Delaunay wrote:
Hi Vinod,
Thanks for the review.
On 5/4/24 14:40, Vinod Koul wrote:
On 23-04-24,
On Wed, May 15, 2024 at 10:12:20AM -0700, Justin Stitt wrote:
> Hi Peter,
>
> On Wed, May 15, 2024 at 12:36 AM Peter Zijlstra wrote:
> >
> > On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> > > For example, the most common case of overflow we've ever had has very
> > > much been
23 matches
Mail list logo
