On Wed, 24 Apr 2024, Kees Cook wrote:
> Please don't move variable definitions into the middle of the function
> body. :)
I have moved the parent_node declaration back to the top of the function body.
Patch v2:
https://lore.kernel.org/all/20240605214944.22113-1-jain.abhinav...@gmail.com/
Add __free(device_node) to the parent_node struct declaration
Add changes to incorporate the review comments from v1
Signed-off-by: Abhinav Jain
PATCH v1 link:
https://lore.kernel.org/all/20240415161409.8375-1-jain.abhinav...@gmail.com/
Changes since v1:
- Moved the variable definition back to
On Tue, Jun 04, 2024 at 05:49:20PM -0700, Kees Cook wrote:
> On Tue, Jun 04, 2024 at 04:13:32PM -0600, Tycho Andersen wrote:
> > On Tue, Jun 04, 2024 at 04:02:28PM +0100, Simon Horman wrote:
> > > On Fri, May 31, 2024 at 12:14:56PM -0700, Kees Cook wrote:
> > > > + for (idx = 0; idx < ARRAY_S
> > Which types exactly do you mean when you're looking at the severities[]
> > array in severity.c?
> >
> > And what scenario are you talking about?
> >
> > To get an #MC exception and detect only UCNA/SRAO errors? Can that even
> > happen on any hardware?
> >
>
> Yes, I mean an #MC exception happ
req->n_channels must be set before req->channels[] can be used.
This patch fixes one of the issues encountered in [1].
[ 83.964252] [ cut here ]
[ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4
[ 83.964258] index 0 is out of range for type '
On 24/06/04 09:29PM, Johannes Berg wrote:
> Looking at your patch again, this seems wrong?
>
> > + local->hw_scan_req->req.channels[*n_chans++] =
> > req->channels[i];
> >
>
> This will increment n_chans rather than *n
On 2024/6/5 19:33, Borislav Petkov wrote:
[这封邮件来自外部发件人 谨防风险]
On Wed, Jun 05, 2024 at 06:10:07PM +0800, Tony W Wang-oc wrote:
It may also happen without setting fake_panic, such as an MCE error of the
UCNA/SRAO type occurred?
Which types exactly do you mean when you're looking at the seve
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in
../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in
../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in
../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.015950] UBSAN: signed-integer-overflow in
../drivers/cdrom/cdrom.c:2361:33
[ 366.021089] -9223372036
On Wed, Jun 05, 2024 at 06:10:07PM +0800, Tony W Wang-oc wrote:
> It may also happen without setting fake_panic, such as an MCE error of the
> UCNA/SRAO type occurred?
Which types exactly do you mean when you're looking at the severities[]
array in severity.c?
And what scenario are you talking ab
On 2024/6/5 17:36, Borislav Petkov wrote:
[这封邮件来自外部发件人 谨防风险]
On Wed, Jun 05, 2024 at 02:23:32PM +0800, Tony W Wang-oc wrote:
After MCE has occurred, it is possible for the MCE handler to execute the
add_taint() function without panic. For example, the fake_panic is
configured.
fake_panic
On Wed, Jun 05, 2024 at 02:23:32PM +0800, Tony W Wang-oc wrote:
> After MCE has occurred, it is possible for the MCE handler to execute the
> add_taint() function without panic. For example, the fake_panic is
> configured.
fake_panic is an ancient debugging leftover. If you set it, you get what
yo
On Tue, Jun 04, 2024 at 10:33:49AM +0100, Simon Horman wrote:
> On Fri, May 31, 2024 at 08:37:41AM -0700, Shradha Gupta wrote:
> > Allow variable size indirection table allocation in MANA instead
> > of using a constant value MANA_INDIRECT_TABLE_SIZE.
> > The size is now derived from the MANA_QUERY
15 matches
Mail list logo