On Mon, Jul 15, 2024 at 01:17:10PM -0700, Kees Cook wrote:
> On Mon, Jul 15, 2024 at 08:04:21PM +0200, Mickaël Salaün wrote:
> > Yes, that's why we use WARN_ON_ONCE() to check cases that should never
> > happen (at the time of writting), but in practice it's useful to check
> > (with fuzzing) that
Hello Ian,
On 7/15/2024 8:52 PM, Ian Rogers wrote:
> On Mon, Jul 15, 2024 at 2:36 AM Dhananjay Ugwekar
> wrote:
>>
>> Hello Ian,
>>
>> On 7/12/2024 3:53 AM, Ian Rogers wrote:
>>> On Thu, Jul 11, 2024 at 3:25 AM Dhananjay Ugwekar
>>> wrote:
Currently the energy-cores event in the power
Hello Peter, Rui,
After Ian's comments on the series, I have decided to rethink the approach of
adding a new PMU for the per-core RAPL counters.
However this patch is still needed as a fix for the
commit ("x86/cpu/topology: Add support for the AMD 0x8026 leaf"), I will be
sending this separa
On 7/15/24 11:41, Simon Horman wrote:
On Sat, Jul 13, 2024 at 09:11:15PM -0700, Kees Cook wrote:
Replace the deprecated[1] uses of strncpy() in tcp_ca_get_name_by_key()
and tcp_get_default_congestion_control(). The callers use the results as
standard C strings (via nla_put_string() and proc hand
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
From: Anjali K
[ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in
On Tue, Jul 16, 2024 at 4:32 AM Paolo Abeni wrote:
>
> On 7/15/24 11:41, Simon Horman wrote:
> > On Sat, Jul 13, 2024 at 09:11:15PM -0700, Kees Cook wrote:
> >> Replace the deprecated[1] uses of strncpy() in tcp_ca_get_name_by_key()
> >> and tcp_get_default_congestion_control(). The callers use th
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Sat, 13 Jul 2024 21:11:15 -0700 you wrote:
> Replace the deprecated[1] uses of strncpy() in tcp_ca_get_name_by_key()
> and tcp_get_default_congestion_control(). The callers use the results as
> standard C strings (
Looking at https://syzkaller.appspot.com/bug?extid=d5dc2801166df6d34774
and trying to reproduce it with CONFIG_UBSAN enabled, I've noticed the
following:
UBSAN: array-index-out-of-bounds in net/wireless/sme.c:95:3
index 0 is out of range for type 'struct ieee80211_channel *[]'
CPU: 3 PID: 4993 Com
Hi Masahiro,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.10 next-20240716]
[cannot apply to akpm-mm/mm-nonmm-unstable kees/for-next/hardening
kees/for-next/pstore kees/for-next/kspp]
[If your patch is applied to the
On Tue, Jul 16, 2024 at 08:40:11PM +0300, Dmitry Antipov wrote:
> Looking at https://syzkaller.appspot.com/bug?extid=d5dc2801166df6d34774
> and trying to reproduce it with CONFIG_UBSAN enabled, I've noticed the
> following:
>
> UBSAN: array-index-out-of-bounds in net/wireless/sme.c:95:3
> index 0
On Mon, 15 Jul 2024 at 09:29, Kees Cook wrote:
>
> Please pull these small pstore updates for v6.11-rc1. (Note that since there
> were no pstore updates for v6.10, this is based on v6.9-rc2. I forgot
> to do my traditional merge-on-rc2 for this tree when v6.10-rc2 happened.)
Note that this is exa
With the new __counted_by annotation, the "num_leds" variable needs to
valid for accesses to the "leds" array. This requirement is not met in
gpio_leds_create(), since "num_leds" starts at "0", so "leds" index "0"
will not be considered valid (num_leds would need to be "1" to access
index "0").
Fi
With the new __counted_by annotation, the "lli_size" variable needs to
valid for accesses to the "lli" array. This requirement is not met in
stm32_dma3_chan_desc_alloc(), since "lli_size" starts at "0", so "lli"
index "0" will not be considered valid during the initialization for loop.
Fix this by
The pull request you sent on Mon, 15 Jul 2024 09:29:29 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
> tags/pstore-v6.11-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8050258bd1eed0f77dd7e3fa15feb23bbcc38e63
Thank you!
--
Deet-doot-do
With the new __counted_by annotation, the "num_nodes" struct member must
be set before accessing the "nodes" array. This initialization was done
in other places where a new struct icc_onecell_data is allocated, but this
case in icc_clk_register() was missed. Set "num_nodes" after allocation.
Fixes
On 16/07/24 15:24, Kees Cook wrote:
With the new __counted_by annotation, the "num_leds" variable needs to
valid for accesses to the "leds" array. This requirement is not met in
gpio_leds_create(), since "num_leds" starts at "0", so "leds" index "0"
will not be considered valid (num_leds would
On 16/07/24 15:38, Kees Cook wrote:
With the new __counted_by annotation, the "lli_size" variable needs to
valid for accesses to the "lli" array. This requirement is not met in
stm32_dma3_chan_desc_alloc(), since "lli_size" starts at "0", so "lli"
index "0" will not be considered valid during
On 16/07/24 15:48, Kees Cook wrote:
With the new __counted_by annotation, the "num_nodes" struct member must
be set before accessing the "nodes" array. This initialization was done
in other places where a new struct icc_onecell_data is allocated, but this
case in icc_clk_register() was missed.
With the new __counted_by annocation, the "sglen" struct member must
be set before accessing the "sg" array. This initialization was done in
other places where a new struct omap_desc is allocated, but these cases
were missed. Set "sglen" after allocation.
Fixes: b85178611c11 ("dmaengine: ti: omap-
On Tue, Jul 16, 2024 at 1:42 AM Dhananjay Ugwekar
wrote:
>
> Hello Ian,
>
> On 7/15/2024 8:52 PM, Ian Rogers wrote:
> > On Mon, Jul 15, 2024 at 2:36 AM Dhananjay Ugwekar
> > wrote:
> >>
> >> Hello Ian,
> >>
> >> On 7/12/2024 3:53 AM, Ian Rogers wrote:
> >>> On Thu, Jul 11, 2024 at 3:25 AM Dhananj
On 16/07/24 15:57, Kees Cook wrote:
With the new __counted_by annocation, the "sglen" struct member must
be set before accessing the "sg" array. This initialization was done in
other places where a new struct omap_desc is allocated, but these cases
were missed. Set "sglen" after allocation.
F
On Wed, Jul 17, 2024 at 2:51 AM kernel test robot wrote:
>
> Hi Masahiro,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v6.10 next-20240716]
> [cannot apply to akpm-mm/mm-nonmm-unstable
27 matches
Mail list logo
