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?
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
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
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
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
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 ]
> > [
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
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
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
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
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:
...
> > > +
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
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
-
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.
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.
>
>
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,
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
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
21 matches
Mail list logo
