Hi,
we currently think this is due to a race condition in the packet queue
code. Ivo is currently reworking the packet queues, which I hope will
resolve this situation.
Mattias
On Thu, 2008-01-17 at 22:57 +0100, Alejandro Riveira Fernández wrote:
> Running
>
> Linux Varda 2.6.24-rc8 #1 SMP PREE
; (the none I sent earlier was from -git4, by the way)
> > >
> > > Call Trace:
> > > [] __update_rq_clock+0x1a/0xf0
> > > [] rt2x00lib_txdone+0x9d/0xd0 [rt2x00lib]
> > > [] rt61pci_txdone+0x153/0x1f0 [rt61pci]
> > > [] rt61pci_interrupt+0x9d/0xb0 [rt61p
This makes debugfs use its own file_operations for the value accessor files
created by debugfs_create_XXX. Having that, we can also have proper versions
for signed integers.
Signed-off-by: Mattias Nissler <[EMAIL PROTECTED]>
---
When writing some debugfs code for mac80211 I wanted to have
On Sun, 2007-12-16 at 09:05 -0800, Greg KH wrote:
> On Sun, Dec 16, 2007 at 05:37:59PM +0100, Mattias Nissler wrote:
> > This makes debugfs use its own file_operations for the value accessor files
> > created by debugfs_create_XXX. Having that, we can also have proper versions
On Fri, Jan 15, 2021 at 6:46 AM Sai Prakash Ranjan
wrote:
>
> Hello Mathieu, Suzuki
>
> On 2020-10-15 21:32, Mathieu Poirier wrote:
> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> >> On production systems with ETMs enabled, it is preferred to
> >> exclude kernel mode(NS E
On Wed, Aug 13, 2014 at 11:57 PM, Greg KH wrote:
>
> On Wed, Aug 13, 2014 at 02:57:05PM -0700, Matt Longnecker wrote:
> > Greg,
> >
> > Back in December 2007 Mattias Nissler proposed a patch defining
> > debugfs_create_s32 and friends. In it he reworked the already
; > >
> > > Prevent this by using POLLFREE when the thread exits.
> > >
> > > Signed-off-by: Martijn Coenen
> > > Reported-by: syzbot
> > > Cc: stable # 4.14
> > > [backport BINDER_LOOPER_STATE_POLL logic as well]
> > &
On Mon, Nov 21, 2016 at 6:10 PM, James Bottomley
wrote:
> On Wed, 2016-11-16 at 13:18 -0800, Mattias Nissler wrote:
>> I understand that silence suggests there's little interest, but
>> here's some new information I discovered today that may justify to
>> recon
freebsd/freebsd/blob/a41f4cc9a57cd74604ae7b051eec2f48865f18d6/sys/kern/vfs_lookup.c#L939
There's also some evidence on the net that people have been using said
nosymfollow mount option to mitigate symlink attacks.
On Mon, Oct 24, 2016 at 7:09 AM, Mattias Nissler wrote:
> Friendly ping - does this v
Setting the "nosymfollow" mount option helps prevent privileged
writers from modifying files unintentionally in case there is an
unexpected link along the accessed path. The "nosymfollow" option is
thus useful as a defensive measure for systems that need to deal with
untrus
On Thu, Nov 17, 2016 at 1:43 PM, Austin S. Hemmelgarn
wrote:
> On 2016-11-16 16:18, Mattias Nissler wrote:
>>
>> I understand that silence suggests there's little interest, but here's
>> some new information I discovered today that may justify to reconsider
>&
Friendly ping - does this version of the patch have any chance on
getting included in mainline?
On Wed, Oct 19, 2016 at 2:31 PM, Mattias Nissler wrote:
> For mounts that have the new "nosymlinks" option, don't follow
> symlinks when resolving paths. The new option is simil
ull
control of the attacker, who can place symlinks to trick file writes
after reboot to target a file of their choice. "nolinks" fundamentally
prevents this.
Signed-off-by: Mattias Nissler
---
fs/namei.c | 9 -
fs/namespace.c | 8 +---
fs/proc_namespa
On Fri, Oct 14, 2016 at 5:00 PM, Al Viro wrote:
>
> On Fri, Oct 14, 2016 at 03:55:15PM +0100, Al Viro wrote:
> > > Setting the "nolinks" mount option helps prevent privileged writers
> > > from modifying files unintentionally in case there is an unexpected
> > > link along the accessed path. The "
Forgot to mention: I realize my motivation is very specific to Chrome
OS, however the nolinks option seemed useful also as a mitigation to
generic privilege escalation symlink attacks, for cases where
disabling symlinks/hardlinks is acceptable.
On Fri, Oct 14, 2016 at 5:50 PM, Mattias Nissler
ble.
>
> On Fri, Oct 14, 2016 at 5:50 PM, Mattias Nissler
> wrote:
>> On Fri, Oct 14, 2016 at 5:00 PM, Al Viro wrote:
>>>
>>> On Fri, Oct 14, 2016 at 03:55:15PM +0100, Al Viro wrote:
>>> > > Setting the "nolinks" mount option helps prevent
On Tue, Oct 18, 2016 at 5:14 PM, Colin Walters wrote:
>
> On Mon, Oct 17, 2016, at 09:02 AM, Mattias Nissler wrote:
> > OK, no more feedback thus far. Is there generally any interest in a
> > mount option to avoid path name aliasing resulting in target file
> > confusion
expected
link along the accessed path. The "nosymlinks" option is thus useful
as a defensive measure for systems that need to deal with untrusted
file systems in privileged contexts.
Signed-off-by: Mattias Nissler
---
fs/namei.c | 3 +++
fs/namespace.c | 9 ++
18 matches
Mail list logo
