On Thu, Jan 30, 2025 at 5:28 PM 'Sami Tolvanen' via syzkaller-bugs
wrote:
>
> On Thu, Jan 30, 2025 at 5:20 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:a13f6e0f405e Add linux-next specific files for 20250130
> > git tree: linux-next
On Wed, 11 Nov 2020 at 13:44, Aleksandr Nogikh wrote:
>
> From: Aleksandr Nogikh
>
> Fault injection
> capabilities[Documentation/fault-injection/fault-injection.rst]
> facilitate testing of the stability of the Linux kernel by providing
> means to force a number of kernel
From: Aleksandr Nogikh
Add a fault injection capability to call_int_hook macro. This will
facilitate testing of fault tolerance of the code that invokes
security hooks as well as the fault tolerance of the LSM
implementations themselves.
Add a KConfig option (CONFIG_FAIL_LSM_HOOKS) that
From: Aleksandr Nogikh
Describe fail_lsm_hooks fault injection capability.
Signed-off-by: Aleksandr Nogikh
--
v2:
- Added this commit.
---
Documentation/fault-injection/fault-injection.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/fault-injection/fault
From: Aleksandr Nogikh
Fault injection capabilities[Documentation/fault-injection/fault-injection.rst]
facilitate testing of the stability of the Linux kernel by providing
means to force a number of kernel interfaces to return error
codes. This patch series proposes adding such fault injection
On Tue, Nov 10, 2020 at 7:43 AM Tetsuo Handa
wrote:
>
[...]
>
> By the way, fail_lsm_hooks.retval is "signed int" but debugfs_create_u32()
> handles "unsigned int".
> Do we want to allow lsm_hooks_inject_fail() to inject arbitrary
> !IS_ERR_VALUE() values?
Thanks for pointing it out. Technicall
On Thu, 29 Oct 2020 at 21:35, Aleksandr Nogikh
wrote:
>
> From: Aleksandr Nogikh
>
> Fault injection
> capabilities[Documentation/fault-injection/fault-injection.rst]
> facilitate testing of the stability of the Linux kernel by providing
> means to force a number of kernel
From: Aleksandr Nogikh
Describe fail_lsm_hooks fault injection capability.
Signed-off-by: Aleksandr Nogikh
---
v2:
- Added this commit.
---
Documentation/fault-injection/fault-injection.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/fault-injection/fault
From: Aleksandr Nogikh
Add a fault injection capability to call_int_hook macro. This will
facilitate testing of fault tolerance of the code that invokes
security hooks as well as the fault tolerance of the LSM
implementations themselves.
Add a KConfig option (CONFIG_FAIL_LSM_HOOKS) that
From: Aleksandr Nogikh
Fault injection capabilities[Documentation/fault-injection/fault-injection.rst]
facilitate testing of the stability of the Linux kernel by providing
means to force a number of kernel interfaces to return error
codes. This patch series proposes adding such fault injection
On Wed, Oct 28, 2020 at 10:25 PM Johannes Berg
wrote:
[...]
> Wouldn't it make more sense to push that a layer down
> into ieee80211_rx_napi(), or actually now perhaps even
> better ieee80211_rx_list(), so we get it even if the driver called that
> API in the first place?
>
> You might only care a
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work() and
ieee80211_rx_list(). This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v4 -> v5:
* Using ieee80211_rx_list() instead
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection during
802.11 frames processing. These changes make it possible to perform
coverage-guided fuzzing in search of remotely triggerable bugs.
Normally, KCOV collects coverage information for the code that is
executed
From: Aleksandr Nogikh
kcov_common_handle is a method that is used to obtain a "default" KCOV
remote handle of the current process. The handle can later be passed
to kcov_remote_start in order to collect coverage for the processing
that is initiated by one process, but done in an
From: Aleksandr Nogikh
Remote KCOV coverage collection enables coverage-guided fuzzing of the
code that is not reachable during normal system call execution. It is
especially helpful for fuzzing networking subsystems, where it is
common to perform packet handling in separate work queues even for
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v1 -> v2:
* The commit now affects ieee80211_rx instead
From: Aleksandr Nogikh
Currently it is possible to craft a special netlink RTM_NEWQDISC
command that can result in jitter being equal to 0x8000. It is
enough to set the 32 bit jitter to 0x0200 (it will later be
multiplied by 2^6) or just set the 64 bit jitter via
TCA_NETEM_JITTER64. This
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection during
802.11 frames processing. These changes make it possible to perform
coverage-guided fuzzing in search of remotely triggerable bugs.
Normally, KCOV collects coverage information for the code that is
executed
From: Aleksandr Nogikh
kcov_common_handle is a method that is used to obtain a "default" KCOV
remote handle of the current process. The handle can later be passed
to kcov_remote_start in order to collect coverage for the processing
that is initiated by one process, but done in an
From: Aleksandr Nogikh
Remote KCOV coverage collection enables coverage-guided fuzzing of the
code that is not reachable during normal system call execution. It is
especially helpful for fuzzing networking subsystems, where it is
common to perform packet handling in separate work queues even for
(resending the previous message in a plain/text mode)
On Mon, Oct 26, 2020 at 7:20 PM Casey Schaufler wrote:
>
[...]
> > - int RC = IRC; \
> > - do {\
> > + int RC = lsm_hooks_inject_fail();
On Tue, Oct 27, 2020 at 6:31 PM Akinobu Mita wrote:
>
[...]
> In addition to this global one, what do you think about per-hook fault
> injection,
> i.e. /sys/kernel/debug/fail_lsm_hooks//retval ?
I was thinking about this, but decided to begin with a simple version
that could definitely be useful
On Mon, Oct 26, 2020 at 7:57 PM Willem de Bruijn
wrote:
[...]
> If the handle does not need to be set if zero, why then set it if the
> skb has extensions?
The point of that condition is to avoid unnecessary allocations of skb extension
objects. At the same time, one would expect skb_get_kcov_han
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v1 -> v2:
* The commit now affects ieee80211_rx instead
From: Aleksandr Nogikh
Remote KCOV coverage collection enables coverage-guided fuzzing of the
code that is not reachable during normal system call execution. It is
especially helpful for fuzzing networking subsystems, where it is
common to perform packet handling in separate work queues even for
From: Aleksandr Nogikh
kcov_common_handle is a method that is used to obtain a "default" KCOV
remote handle of the current process. The handle can later be passed
to kcov_remote_start in order to collect coverage for the processing
that is initiated by one process, but done in an
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection during
802.11 frames processing. These changes make it possible to perform
coverage-guided fuzzing in search of remotely triggerable bugs.
Normally, KCOV collects coverage information for the code that is
executed
From: Aleksandr Nogikh
Fault injection capabilities[Documentation/fault-injection/fault-injection.rst]
facilitate testing of the stability of the Linux kernel by providing
means to force a number of kernel interfaces to return error
codes. This RFC proposes adding such fault injection capability
From: Aleksandr Nogikh
Describe fail_lsm_hooks fault injection capability.
Signed-off-by: Aleksandr Nogikh
---
v2:
- Added this commit.
---
Documentation/fault-injection/fault-injection.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/fault-injection/fault
From: Aleksandr Nogikh
Add a fault injection capability to call_int_hook macro. This will
facilitate testing of fault tolerance of the code that invokes
security hooks as well as the fault tolerance of the LSM
implementations themselves.
Add a KConfig option (CONFIG_FAIL_LSM_HOOKS) that
On Thu, Oct 15, 2020 at 10:04 PM Willem de Bruijn
wrote:
>
> On Tue, Oct 13, 2020 at 12:50 PM Jakub Kicinski wrote:
> >
> > On Tue, 13 Oct 2020 18:59:28 +0300 Aleksandr Nogikh wrote:
> > > On Mon, 12 Oct 2020 at 09:04, Dmitry Vyukov wrote:
> > > >
> &
From: Aleksandr Nogikh
Currently it is possible to craft a special netlink RTM_NEWQDISC
command that result in jitter being equal to 0x8000. It is enough
to set 32 bit jitter to 0x0200 (it will later be multiplied by
2^6) or set 64 bit jitter via TCA_NETEM_JITTER64. This causes an
On Thu, 15 Oct 2020 at 18:30, Serge E. Hallyn wrote:
[...]
> seeing 'should_fail' here, kind of out of context, would be confusing to
> thousands of ppl reading the code and wondering why it should fail. maybe
> "inject_fail_lsm_hook()" ?
Sounds reasonable, thank you for the suggestion. I'll ren
From: Aleksandr Nogikh
Add a fault injection capability to call_int_hook macro. This will
facilitate testing of fault tolerance of the code that invokes
security hooks as well as the fault tolerance of the LSM
implementations themselves.
Add a KConfig option (CONFIG_FAIL_LSM_HOOKS) that
From: Aleksandr Nogikh
Fault injection capabilities[Documentation/fault-injection/fault-injection.rst]
facilitate testing of the stability of the Linux kernel by providing
means to force a number of kernel interfaces to return error
codes. This RFC proposes adding such fault injection capability
On Mon, 12 Oct 2020 at 09:04, Dmitry Vyukov wrote:
>
> On Sat, Oct 10, 2020 at 5:14 PM Jakub Kicinski wrote:
> >
> > On Sat, 10 Oct 2020 09:54:57 +0200 Dmitry Vyukov wrote:
> > > On Sat, Oct 10, 2020 at 1:16 AM Jakub Kicinski wrote:
[...]
> > > > Could you use skb_extensions for this?
> > >
> >
On Sun, 11 Oct 2020 at 21:50, Johannes Berg wrote:
[...]
> Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if
> it'd be helpful to have an easier raw 802.11 inject path on top of say
> hwsim0; I noticed some syzbot reports where it created raw sockets, but
> that only gets yo
On Mon, 12 Oct 2020 at 10:12, Johannes Berg wrote:
[...]
> > @@ -233,6 +233,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t
> > gfp_mask,
> > skb->end = skb->tail + size;
> > skb->mac_header = (typeof(skb->mac_header))~0U;
> > skb->transport_header = (typeof(skb->trans
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of mac80211
code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v2:
* The commit now affects ieee80211_rx instead of
From: Aleksandr Nogikh
kcov_common_handle is a method that is used to obtain a "default" KCOV
remote handle of the current process. The handle can later be passed
to kcov_remote_start in order to collect coverage for the processing
that is initiated by one process, but done in an
From: Aleksandr Nogikh
Remote KCOV coverage collection enables coverage-guided fuzzing of the
code that is not reachable during normal system call execution. It is
especially helpful for fuzzing networking subsystems, where it is
common to perform packet handling in separate work queues even for
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection during
802.11 frames processing. These changes make it possible to perform
coverage-guided fuzzing in search of remotely triggerable bugs.
Normally, KCOV collects coverage information for the code that is
executed
On Wed, 7 Oct 2020 at 14:48, Johannes Berg wrote:
>
> On Wed, 2020-10-07 at 10:17 +, Aleksandr Nogikh wrote:
[...]
> > Aleksandr Nogikh (2):
> > net: store KCOV remote handle in sk_buff
>
> Can you explain that a bit better? What is a "remote handle"? W
From: Aleksandr Nogikh
This patch series enables remote KCOV coverage collection for the
mac80211 code that processes incoming 802.11 frames. These changes
make it possible to perform coverage-guided fuzzing in search of
remotely triggerable bugs.
The series consists of two commits.
1
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_tasklet_handler. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
net/mac80211/iface.c | 2 ++
net/mac80211/main.c | 2
From: Aleksandr Nogikh
Remote KCOV coverage collection enables coverage-guided fuzzing of the
code that is not reachable during normal system call execution. It is
especially helpful for fuzzing networking subsystems, where it is
common to perform packet handling in separate work queues even for
46 matches
Mail list logo