This should have been fixed by this commit in amd-staging-drm-next:
https://lore.kernel.org/patchwork/patch/1392368/
commit b8aff1f3a0b3d8434f8ccf5d3017137c29aca77b
Author: Felix Kuehling
Date: Mon Mar 8 22:15:42 2021 -0500
drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Using
On Sun, 7 Mar 2021, Joe Perches wrote:
> On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
> >
> > On Wed, 3 Mar 2021, Joe Perches wrote:
> >
> > > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > > Here is a possible
On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
>
> On Wed, 3 Mar 2021, Joe Perches wrote:
>
> > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > Here is a possible opportunity to reduce data usage in the kernel.
> > > >
> >
On Wed, 3 Mar 2021, Joe Perches wrote:
> On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > On 02/03/2021 18.42, Joe Perches wrote:
> > > Here is a possible opportunity to reduce data usage in the kernel.
> > >
> > > $ git grep -P -n
On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> On 02/03/2021 18.42, Joe Perches wrote:
> > Here is a possible opportunity to reduce data usage in the kernel.
> >
> > $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]'
> > drivers/ | \
> > grep -v __initdata
: "Peilin Ye"
> Cc: "Marcel Holtmann" , "Johan Hedberg"
> , "Andrei Emeltchenko"
> , "Greg Kroah-Hartman"
> , "David S. Miller" , "Jakub
> Kicinski" , linux-kernel-ment...@lists.linuxfoundation.org,
> &
linuxfoundation.org, "syzkaller-bugs"
, "linux-bluetooth"
, "netdev" , "LKML"
, gtiw...@redhat.com,
syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
Sent: Wednesday, March 3, 2021 1:51:41 PM
Subject: Re: [Linux-kernel-mentees] [PATCH net] Bluetooth:
On Sat, Aug 8, 2020 at 6:06 AM Peilin Ye wrote:
>
> Prevent amp_read_loc_assoc_final_data() from dereferencing `mgr` as NULL.
>
> Reported-and-tested-by: syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
> Fixes: 9495b2ee757f ("Bluetooth: AMP: Process Chan Selected event")
> Signed-off-by:
On 02/03/2021 18.42, Joe Perches wrote:
> Here is a possible opportunity to reduce data usage in the kernel.
>
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]'
> drivers/ | \
> grep -v __initdata | \
> wc -l
> 3250
>
> Meaning there are ~3000 declarations of
Hi all!
On 02/03/2021 18:42, Joe Perches wrote:
[...]
> - For instance: (head -10 of the git grep for file statics)
>
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16,
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[]
On Mon, Mar 1, 2021 at 8:10 AM Lukas Bulwahn wrote:
>
> Hi,
>
> On Mon, Mar 1, 2021 at 7:58 AM wrote:
> >
> > This is the first time for me to report something, so maybe the format is
> > not right. Please correct me if I'm wrong. Thank you ~
> > When using Syzkaller to fuzz Linux kernel
Hi,
On Mon, Mar 1, 2021 at 7:58 AM wrote:
>
> This is the first time for me to report something, so maybe the format is not
> right. Please correct me if I'm wrong. Thank you ~
> When using Syzkaller to fuzz Linux kernel 5.11.0, it reported one
> null-ptr-def bug in file.c. The information is
On Tue, Feb 02, 2021 at 04:48:04AM -0800, Joe Perches wrote:
> On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> > The idea of a bot seems nice though in general.
> > People do have all the style checking scripts at their disposal, but still
> > we see style issues on the list.
> >
> >
On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> The idea of a bot seems nice though in general.
> People do have all the style checking scripts at their disposal, but still
> we see style issues on the list.
>
> Something similar to the kernel test robot, but for style issues seems
On Mon, Feb 01, 2021 at 10:31:33PM +0530, Dwaipayan Ray wrote:
> On Mon, Feb 1, 2021 at 10:07 PM Greg KH wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
On Mon, Feb 01, 2021 at 05:50:45PM +0100, Lukas Bulwahn wrote:
>
> Dwaipayan, there are two ways:
> - We build a bot listening to mailing lists and check. I like that
> implementation idea for various other checks.
> - Stephen Rothwell could include this as a check on linux-next and
> inform the
On Mon, Feb 1, 2021 at 10:20 PM Lukas Bulwahn wrote:
>
> On Mon, Feb 1, 2021 at 5:37 PM Greg KH wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
> > >
On Mon, Feb 1, 2021 at 10:07 PM Greg KH wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches
On Mon, Feb 1, 2021 at 5:37 PM Greg KH wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches
On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> Hi,
> on linux-next,
> $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> gives:
> 4a2d78822fdf
> 12ca45fea91c
> 09f2724a786f
>
> These are patches from the year 2085, 2037 and 2030 respectively.
>
> Would a
On Tue, Jan 12, 2021 at 11:46:55AM +0100, Jessica Yu wrote:
> +++ Adam Zabrocki [12/01/21 01:15 +0100]:
> > Hello,
> >
> > On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
> > > +++ Adam Zabrocki [10/01/21 18:54 +0100]:
> > > > Hello,
> > > >
> > > > I believe that the following commit
+++ Adam Zabrocki [12/01/21 01:15 +0100]:
Hello,
On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
+++ Adam Zabrocki [10/01/21 18:54 +0100]:
> Hello,
>
> I believe that the following commit does introduce a gentle "functionality
> bug":
>
> "module: delay kobject uevent until after
Hello,
On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
> +++ Adam Zabrocki [10/01/21 18:54 +0100]:
> > Hello,
> >
> > I believe that the following commit does introduce a gentle "functionality
> > bug":
> >
> > "module: delay kobject uevent until after module init call":
> >
+++ Adam Zabrocki [10/01/21 18:54 +0100]:
Hello,
I believe that the following commit does introduce a gentle "functionality
bug":
"module: delay kobject uevent until after module init call":
CC linux-doc
?? 2020/12/23 11:03, ?? :
> ??
> ?0?2 ?0?2 ?0?2
> Linuxkernel??Documentation/translations/zh_CN
On Thu, Dec 17, 2020 at 10:45 PM Pavel Machek wrote:
>
> Well.. not everyone has 32 cores in their notebook.
It is true that complex Rust, like complex C++, does have high
compilation times. But it all depends on how much one relies on
certain language features. Straightforward Rust code is
On Tue 2020-07-28 23:34:17, Josh Triplett wrote:
> On Tue, Jul 28, 2020 at 10:40:38PM +0200, Pavel Machek wrote:
> > > We just need to make sure that any kernel CI infrastructure tests that
> > > right away, then, so that failures don't get introduced by a patch from
> > > someone without a Rust
On Thu, 2020-12-03 at 20:25 +0100, Greg KH wrote:
> On Thu, Dec 03, 2020 at 08:00:58PM +0100, Lukas Bulwahn wrote:
> > On Thu, Dec 3, 2020 at 7:56 PM Greg KH wrote:
> > >
> > > On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > > > On Thu, Dec 3, 2020 at 10:59 AM Aditya wrote:
>
On Thu, Dec 03, 2020 at 08:00:58PM +0100, Lukas Bulwahn wrote:
> On Thu, Dec 3, 2020 at 7:56 PM Greg KH wrote:
> >
> > On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > > On Thu, Dec 3, 2020 at 10:59 AM Aditya wrote:
> > > >
> > > > On 3/12/20 12:26 am, Joe Perches wrote:
> > >
On Thu, Dec 3, 2020 at 7:56 PM Greg KH wrote:
>
> On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > On Thu, Dec 3, 2020 at 10:59 AM Aditya wrote:
> > >
> > > On 3/12/20 12:26 am, Joe Perches wrote:
> > > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > > >>
On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> On Thu, Dec 3, 2020 at 10:59 AM Aditya wrote:
> >
> > On 3/12/20 12:26 am, Joe Perches wrote:
> > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > >> Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage
On Fri, 2020-03-06 at 16:07 -0800, Joe Perches wrote:
> On Fri, 2020-03-06 at 11:02 -0800, Nick Desaulniers wrote:
> > Turns out there are hundreds of unused static inline
> > > functions in kernel .h files.
> > >
> > > A trivial script to find some of them (with likely
> > > false positives as
On Fri, 20 Nov 2020 00:40:43 +0530 Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurrence of the
> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> and it is initialized in rose_add_loopback_neigh()
On Sat, Nov 14, 2020 at 11:18:38AM -0800, Jakub Kicinski wrote:
> On Wed, 11 Nov 2020 22:29:54 +0530 Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurrence of the
> > `neigh` is in rose_loopback_timer() as
On Wed, 11 Nov 2020 22:29:54 +0530 Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurrence of the
> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> and it is initialized in rose_add_loopback_neigh()
On Mon, Nov 09, 2020 at 01:16:53PM +0100, Marcel Holtmann wrote:
> Hi Peilin,
>
> > `num_reports` is not being properly checked. A malformed event packet with
> > a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
> > of bounds. Fix it.
> >
> > Cc: sta...@vger.kernel.org
Hello Sir,
On Tue, Nov 10, 2020 at 09:58:15AM -0800, Jakub Kicinski wrote:
> On Sun, 8 Nov 2020 00:48:35 +0530 Anmol Karn wrote:
> > + dev = rose_dev_get(dest);
>
> this calls dev_hold internally, you never release that reference in
> case ..neigh->dev is NULL
>
> > +
On Sun, 8 Nov 2020 00:48:35 +0530 Anmol Karn wrote:
> + dev = rose_dev_get(dest);
this calls dev_hold internally, you never release that reference in
case ..neigh->dev is NULL
> + if (rose_loopback_neigh->dev && dev) {
Hi Peilin,
> `num_reports` is not being properly checked. A malformed event packet with
> a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
> of bounds. Fix it.
>
> Cc: sta...@vger.kernel.org
> Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct
>
Hello,
Sorry for this wrong subject(It should be v3 instead of v2),
please ignore this patch.
I will send a new one with the corrected subject.
Thanks,
Anmol
On Sun, Nov 8, 2020 at 12:27 AM Anmol Karn wrote:
>
> rose_send_frame() dereferences `neigh->dev` when called from
>
Hello Sir,
On Fri, Nov 06, 2020 at 01:04:27PM -0800, Saeed Mahameed wrote:
> On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurance of the `neigh`
> > is in
On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> is in rose_loopback_timer() as `rose_loopback_neigh`, and it is
> initialized
> in rose_add_loopback_neigh()
On Sun, Nov 01, 2020 at 12:02:58PM +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 04:24:13PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > > > On Thu, Oct 15, 2020 at 07:12:25AM +0200,
On Fri, Oct 30, 2020 at 04:24:13PM +0530, Anmol Karn wrote:
> On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> > On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > > On Thu, Oct 15, 2020 at 05:47:12AM +0530,
On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > In rose_send_frame(), when comparing two
On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > In rose_send_frame(), when comparing two
On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > In rose_send_frame(), when comparing two ax.25 addresses, it assigns
> > > rose_call to
> > > either global
On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > In rose_send_frame(), when comparing two ax.25 addresses, it assigns
> > rose_call to
> > either global ROSE callsign or default port, but when the former block
> >
On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> In rose_send_frame(), when comparing two ax.25 addresses, it assigns
> rose_call to
> either global ROSE callsign or default port, but when the former block
> triggers and
> rose_call is assigned by (ax25_address
Hello sir,
On Sun, Oct 11, 2020 at 10:24 PM Jakub Kicinski wrote:
>
> On Sun, 11 Oct 2020 02:39:29 +0530 Anmol Karn wrote:
> > Flag ``ETHTOOL_A_STRSET_COUNTS_ONLY`` tells the kernel to only return the
> > string
> > counts of the sets, but, when req_info->counts_only tries to read the
> >
On Sun, 11 Oct 2020 02:39:29 +0530 Anmol Karn wrote:
> Flag ``ETHTOOL_A_STRSET_COUNTS_ONLY`` tells the kernel to only return the
> string
> counts of the sets, but, when req_info->counts_only tries to read the
> tb[ETHTOOL_A_STRSET_COUNTS_ONLY] it gets out of bound.
>
> - net/ethtool/strset.c
On 20-09-2020 01:47, Anant Thazhemadam wrote:
> On 19-09-2020 17:03, Anant Thazhemadam wrote:
>> On 19-09-2020 22:25, Al Viro wrote:
>>> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
>>>
Lovely... That would get an empty path and non-directory for a starting
point, but it
On Thu, 2020-10-01 at 13:02 +0530, Anant Thazhemadam wrote:
> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
unrelated trivia:
> diff --git a/drivers/net/usb/rtl8150.c
On Fri, Oct 02, 2020 at 07:06:38PM -0700, David Miller wrote:
> From: Anant Thazhemadam
> Date: Wed, 30 Sep 2020 10:47:20 +0530
>
> > The structures virtnet_info and receive_queue have byte holes in
> > middle, and their members could do with some rearranging
> > (order-of-declaration wise) in
From: Anant Thazhemadam
Date: Wed, 30 Sep 2020 10:47:20 +0530
> The structures virtnet_info and receive_queue have byte holes in
> middle, and their members could do with some rearranging
> (order-of-declaration wise) in order to overcome this.
>
> Rearranging the members helps in:
> *
On 02/10/20 3:52 pm, Hans de Goede wrote:
> Hi,
>
> On 10/1/20 9:43 PM, Anant Thazhemadam wrote:
>> When h5_close() gets called, the memory allocated for the hu gets
>> freed only if hu->serdev doesn't exist. This leads to a memory leak.
>> So when h5_close() is requested, close the serdev device
Hi,
On 10/1/20 9:43 PM, Anant Thazhemadam wrote:
When h5_close() gets called, the memory allocated for the hu gets
freed only if hu->serdev doesn't exist. This leads to a memory leak.
So when h5_close() is requested, close the serdev device instance and
free the memory allocated to the hu
From: Anant Thazhemadam
Date: Thu, 1 Oct 2020 13:02:20 +0530
> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
>
> Checking for the return values appropriately, and handling the
On Thu, Oct 1, 2020 at 2:58 PM Jan Kara wrote:
>
> On Thu 01-10-20 14:35:47, Anmol Karn wrote:
> > d_really_is_negative() checks for the dentry->d_inode whether it's NULL
> > or not, but in open_xa_root(), when it checks 'privroot->d_inode', it
> > doesn't check whether privroot is NULL or not,
On Thu 01-10-20 14:35:47, Anmol Karn wrote:
> d_really_is_negative() checks for the dentry->d_inode whether it's NULL
> or not, but in open_xa_root(), when it checks 'privroot->d_inode', it
> doesn't check whether privroot is NULL or not, this leads to a null
> pointer dereference while calling it
On 26/09/20 1:16 pm, Marcel Holtmann wrote:
> Hi Anant,
>
>> When the amount of data stored in the location corresponding to
>> iov_iter *from is less then 4, some data seems to go uninitialized.
>>
>> Updating this condition accordingly, makes sense both intuitively and
>> logically as well,
On 01/10/20 12:38 pm, Marcel Holtmann wrote:
> Hi Anant,
>
>> When h5_close() gets called, the memory allocated for the hu gets
>> freed only if hu->serdev doesn't exist. This leads to a memory leak.
>> So when h5_close() is requested, close the serdev device instance and
>> free the memory
Hi Anant,
> When h5_close() gets called, the memory allocated for the hu gets
> freed only if hu->serdev doesn't exist. This leads to a memory leak.
> So when h5_close() is requested, close the serdev device instance and
> free the memory allocated to the hu entirely instead.
>
> Fixes:
On 30/09/20 9:46 pm, Dmitry Vyukov wrote:
> On Wed, Sep 30, 2020 at 5:57 PM Anant Thazhemadam
> wrote:
>> On 26/09/20 12:27 pm, Greg KH wrote:
>>> On Sat, Sep 26, 2020 at 08:53:07AM +0200, Dmitry Vyukov via
>>> Linux-kernel-mentees wrote:
On Sat, Sep 26, 2020 at 5:25 AM syzbot
On Wed, Sep 30, 2020 at 5:57 PM Anant Thazhemadam
wrote:
> On 26/09/20 12:27 pm, Greg KH wrote:
> > On Sat, Sep 26, 2020 at 08:53:07AM +0200, Dmitry Vyukov via
> > Linux-kernel-mentees wrote:
> >> On Sat, Sep 26, 2020 at 5:25 AM syzbot
> >> wrote:
> >>> Hello,
> >>>
> >>> syzbot has tested the
On 26/09/20 12:27 pm, Greg KH wrote:
> On Sat, Sep 26, 2020 at 08:53:07AM +0200, Dmitry Vyukov via
> Linux-kernel-mentees wrote:
>> On Sat, Sep 26, 2020 at 5:25 AM syzbot
>> wrote:
>>> Hello,
>>>
>>> syzbot has tested the proposed patch and the reproducer did not trigger any
>>> issue:
>>>
On 29/09/20 2:17 pm, Petko Manolov wrote:
> On 20-09-29 13:50:28, Anant Thazhemadam wrote:
>> When get_registers() fails (which happens when usb_control_msg() fails)
>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>> as the address.
>>
>> Checking for the return values
On 20-09-29 13:50:28, Anant Thazhemadam wrote:
> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
>
> Checking for the return values appropriately, and handling the case
> wherein
A sample crash report can be found here.
https://syzkaller.appspot.com/text?tag=CrashReport=1748691190
The line where the bug seems to get triggered is,
if (!batadv_compare_eth(hard_iface->net_dev->dev_addr,
net_dev->dev_addr))
Looks like it goes through the list of
Hi Anant,
> When the amount of data stored in the location corresponding to
> iov_iter *from is less then 4, some data seems to go uninitialized.
>
> Updating this condition accordingly, makes sense both intuitively and
> logically as well, since the other check for extreme condition done is if
On Sat, Sep 26, 2020 at 08:53:07AM +0200, Dmitry Vyukov via
Linux-kernel-mentees wrote:
> On Sat, Sep 26, 2020 at 5:25 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot has tested the proposed patch and the reproducer did not trigger any
> > issue:
> >
> > Reported-and-tested-by:
> >
On 05/09/20 7:34 am, Anant Thazhemadam wrote:
> When the amount of data stored in the location corresponding to
> iov_iter *from is less then 4, some data seems to go uninitialized.
>
> Updating this condition accordingly, makes sense both intuitively and
> logically as well, since the other
Hi Pavel,
On 9/25/20 4:47 AM, Pavel Machek wrote:
Hi!
In linux-next, I published TODO list for LED subsystem. Is that
something linux-kernel-mentees could help with?
Best regards,
Pavel
Thanks for putting this list together. Will you
Hi,
On Wed, Sep 23, 2020 at 12:04:05PM +0200, Jan Kara wrote:
> On Tue 22-09-20 11:45:31, Peilin Ye wrote:
> > udf_process_sequence() is leaking memory. Free `data.part_descs_loc`
> > before returning.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 7b78fd02fb19 ("udf: Fix handling of Partition
On Tue 22-09-20 11:45:31, Peilin Ye wrote:
> udf_process_sequence() is leaking memory. Free `data.part_descs_loc`
> before returning.
>
> Cc: sta...@vger.kernel.org
> Fixes: 7b78fd02fb19 ("udf: Fix handling of Partition Descriptors")
> Reported-and-tested-by:
On 19-09-2020 17:03, Anant Thazhemadam wrote:
> On 19-09-2020 22:25, Al Viro wrote:
>> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
>>
>>> Lovely... That would get an empty path and non-directory for a starting
>>> point, but it should end up with LAST_ROOT in nd->last_type. Which
On 19-09-2020 22:25, Al Viro wrote:
> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
>
>> Lovely... That would get an empty path and non-directory for a starting
>> point, but it should end up with LAST_ROOT in nd->last_type. Which should
>> not be able to reach the readers of those
On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
> Lovely... That would get an empty path and non-directory for a starting
> point, but it should end up with LAST_ROOT in nd->last_type. Which should
> not be able to reach the readers of those fields... Which kernel had
> that been on?
On Sat, Sep 19, 2020 at 04:44:51PM +0200, Greg KH wrote:
> > ->dir_uid and ->dir_mode are set when link_path_walk() resolves the pathname
> > to directory + final component. They are used when deciding whether to
> > reject
> > a trailing symlink (on fs.protected_symlinks setups) and whether to
On Thu, Sep 17, 2020 at 01:22:38AM +0100, Al Viro wrote:
> On Tue, Sep 15, 2020 at 10:41:57PM -0700, Eric Biggers wrote:
>
> > Looking at the actual KMSAN report, it looks like it's nameidata::dir_mode
> > or
> > nameidata::dir_uid that is uninitialized. You need to figure out the
> > correct
On 16/09/20 11:52 am, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
>> get_registers() copies whatever memory is written by the
>> usb_control_msg() call even if the underlying urb call ends up failing.
>>
>> If get_registers() fails, or ends up reading 0
On 16/09/20 11:49 am, Petko Manolov wrote:
> On 20-09-16 10:35:40, Anant Thazhemadam wrote:
>> get_registers() copies whatever memory is written by the
>> usb_control_msg() call even if the underlying urb call ends up failing.
> Not true, memcpy() is only called if "ret" is positive.
Right. I'm
On 20-09-16 10:35:40, Anant Thazhemadam wrote:
> get_registers() copies whatever memory is written by the
> usb_control_msg() call even if the underlying urb call ends up failing.
Not true, memcpy() is only called if "ret" is positive.
> If get_registers() fails, or ends up reading 0 bytes,
On 20-09-16 08:22:27, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
> > get_registers() copies whatever memory is written by the
> > usb_control_msg() call even if the underlying urb call ends up failing.
> >
> > If get_registers() fails, or ends up reading 0
On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
> get_registers() copies whatever memory is written by the
> usb_control_msg() call even if the underlying urb call ends up failing.
>
> If get_registers() fails, or ends up reading 0 bytes, meaningless and
> junk register values
On Wed, Sep 16, 2020 at 10:56:56AM +0530, Anant Thazhemadam wrote:
> The KMSAN bug report for the bug indicates that there exists;
> Local variable nd@do_file_open_root created at:
> do_file_open_root+0xa4/0xb40 fs/namei.c:3385
> do_file_open_root+0xa4/0xb40 fs/namei.c:3385
What does this
On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> > On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > > idr_get_next() gives
From: Peilin Ye
Date: Sun, 13 Sep 2020 04:06:05 -0400
> tipc_group_add_to_tree() returns silently if `key` matches `nkey` of an
> existing node, causing tipc_group_create_member() to leak memory. Let
> tipc_group_add_to_tree() return an error in such a case, so that
> tipc_group_create_member()
On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > > and this happens when
On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > and this happens when syzbot does fuzzing, and that warning is
> > expected, but WARN_ON_ONCE()
Hello Sir,
> > I have looked into the Bisected logs and the problem occurs from this
> > commit:
> >
> > 941992d29447 ("ethernet: amd: use IS_ENABLED() instead of checking for
> > built-in or module")
> >
>
> That's just the patch which made the code testable by syzbot. It didn't
>
On Sat, Sep 12, 2020 at 02:40:28PM +0530, Anmol Karn wrote:
> On Thu, Sep 10, 2020 at 01:49:18PM +0300, Dan Carpenter wrote:
> > On Thu, Sep 10, 2020 at 10:04:24AM +0530, Anmol Karn wrote:
> > > Prevent hci_phy_link_complete_evt() from dereferencing 'hcon->amp_mgr'
> > > as NULL. Fix it by adding
On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> and this happens when syzbot does fuzzing, and that warning is
> expected, but WARN_ON_ONCE() is not required here and, cecking
> the condition and returning NULL
From: Greg KH
> Sent: 13 September 2020 07:14
> On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
> > The crash report showed that there was a local variable;
> >
> > iovstack.i@__sys_sendmmsg created at:
> > ___sys_sendmsg net/socket.c:2388 [inline]
> >
I can assure you that when I said "I think", I meant it in an assertive manner,
and not an assumptive one, but I can understand how that could easily get lost
in translation.
I wouldn't have sent in the patch if I had caught the build warning, and once
again, my apologies for not fixing it
From: Anant Thazhemadam
Date: Sun, 13 Sep 2020 11:50:52 +0530
> My apologies. I think I ended up overlooking the build warning.
You "think" you overlooked the build warning? You don't actually
know?
If you aren't willing to even make sure the build is clean after your
changes, why should we
On Sat, Sep 12, 2020 at 06:23:36PM -0700, David Miller wrote:
> From: Peilin Ye
> Date: Sat, 12 Sep 2020 06:22:30 -0400
>
> > @@ -291,10 +291,11 @@ static void tipc_group_add_to_tree(struct tipc_group
> > *grp,
> > else if (key > nkey)
> > n = &(*n)->rb_right;
>
On 13/09/20 11:43 am, Greg KH wrote:
> On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
>> The crash report showed that there was a local variable;
>>
>> iovstack.i@__sys_sendmmsg created at:
>> ___sys_sendmsg net/socket.c:2388 [inline]
>> __sys_sendmmsg+0x6db/0xc90
On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
> The crash report showed that there was a local variable;
>
> iovstack.i@__sys_sendmmsg created at:
> ___sys_sendmsg net/socket.c:2388 [inline]
> __sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
>
> that was left
From: Peilin Ye
Date: Sat, 12 Sep 2020 06:22:30 -0400
> @@ -291,10 +291,11 @@ static void tipc_group_add_to_tree(struct tipc_group
> *grp,
> else if (key > nkey)
> n = &(*n)->rb_right;
> else
> - return;
> +
1 - 100 of 1401 matches
Mail list logo
