5.14.10-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 145/172 elf: dont use MAP_FIXED_NOREPLACE for elf interpreter mappings
In reply to Greg Kroah-HartmanFrom: Chen Jingwen <[email protected]>
commit 9b2f72cc0aa4bb444541bb87581c35b7508b37d3 upstream.
In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings") we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp.
Unfortunately, this will cause kernel to fail to start with:
1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already Failed to execute /init (error -17)
The reason is that the elf interpreter (ld.so) has overlapping segments.
readelf -l ld-2.31.so
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000002c94c 0x000000000002c94c R E 0x10000
LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
0x00000000000021e8 0x0000000000002320 RW 0x10000
LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
0x00000000000011ac 0x0000000000001328 RW 0x10000The reason for this problem is the same as described in commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
Not only executable binaries, elf interpreters (e.g. ld.so) can have overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go back to MAP_FIXED in load_elf_interp.
--- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/binfmt_elf.c +1 -1
@@ -630,7 +630,7 @@ static unsigned long load_elf_interp(str vaddr = eppnt->p_vaddr;if (interp_elf_ex->e_type ==ET_EXEC || load_addr_set) - elf_type |=MAP_FIXED_NOREPLACE ; + elf_type |=MAP_FIXED ;else if (no_base && interp_elf_ex->e_type ==ET_DYN ) load_addr = -vaddr;
Greg Kroah-Hartman
maintainerPATCH 146/172 driver core: fw_devlink: Improve handling of cyclic dependencies
In reply to Greg Kroah-HartmanFrom: Saravana Kannan <[email protected]>
commit 2de9d8e0d2fe3a1eb632def2245529067cb35db5 upstream.
When we have a dependency of the form:
Device-A -> Device-C
Device-B
Device-C -> Device-B
Where,
* Indentation denotes "child of" parent in previous line.
* X -> Y denotes X is consumer of Y based on firmware (Eg: DT).
We have cyclic dependency: device-A -> device-C -> device-B -> device-A
fw_devlink current treats device-C -> device-B dependency as an invalid dependency and doesn't enforce it but leaves the rest of the dependencies as is.
While the current behavior is necessary, it is not sufficient if the false dependency in this example is actually device-A -> device-C. When this is the case, device-C will correctly probe defer waiting for device-B to be added, but device-A will be incorrectly probe deferred by fw_devlink waiting on device-C to probe successfully. Due to this, none of the devices in the cycle will end up probing.
To fix this, we need to go relax all the dependencies in the cycle like we already do in the other instances where fw_devlink detects cycles. A real world example of this was reported[1] and analyzed[2].
[1] - https://lore.kernel.org/lkml/[email protected]/
[2] - https://lore.kernel.org/lkml/CAGETcx8peaew90SWiux=TyvuGgvTQOmO4BFALz7aj0Za5QdNFQ@mail.gmail.com/
--- drivers/base/core.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/base/core.c +12 -5
@@ -1790,14 +1790,21 @@ static int fw_devlink_create_devlink(str* be broken by applying logic. Check for these types of cycles and * break them so that devices in the cycle probe properly. * -* If the supplier's parent is dependent on the consumer, then -* the consumer-supplier dependency is a false dependency. So, -* treat it as an invalid link. +* If the supplier's parent is dependent on the consumer, then the +* consumer and supplier have a cyclic dependency. Since fw_devlink +* can't tell which of the inferred dependencies are incorrect, don't +* enforce probe ordering between any of the devices in this cyclic +* dependency. Do this by relaxing all the fw_devlink device links in +* this cycle and by treating the fwnode link between the consumer and +* the supplier as an invalid dependency. */ sup_dev =fwnode_get_next_parent_dev (sup_handle);if (sup_dev &&device_is_dependent (con, sup_dev)) { -dev_dbg (con,"Not linking to %pfwP - False link\n" , - sup_handle); +dev_info (con,"Fixing up cyclic dependency with %pfwP (%s)\n" , + sup_handle,dev_name (sup_dev)); +device_links_write_lock (); +fw_devlink_relax_cycle (con, sup_dev); +device_links_write_unlock (); ret = -EINVAL ; }else {/*
Greg Kroah-Hartman
maintainerPATCH 147/172 debugfs: debugfs_create_file_size(): use IS_ERR to check for error
In reply to Greg Kroah-HartmanFrom: Nirmoy Das <[email protected]>
commit af505cad9567f7a500d34bf183696d570d7f6810 upstream.
debugfs_create_file() returns encoded error so use IS_ERR for checking return value.
--- fs/debugfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/debugfs/inode.c +1 -1
@@ -528,7 +528,7 @@ void debugfs_create_file_size(const char {struct dentry *de =debugfs_create_file (name, mode, parent, data, fops); -if (de) +if (!IS_ERR (de))d_inode (de)->i_size = file_size; }EXPORT_SYMBOL_GPL (debugfs_create_file_size);
Greg Kroah-Hartman
maintainerPATCH 148/172 ipack: ipoctal: fix stack information leak
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit a89936cce87d60766a75732a9e7e25c51164f47c upstream.
The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops).
Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice.
Fixing the ABI is a separate issue, but this at least plugs the security hole.
--- drivers/ipack/devices/ipoctal.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/ipack/devices/ipoctal.c +14 -5
@@ -264,7 +264,6 @@ static int ipoctal_inst_slot(struct ipocint res;int i;struct tty_driver *tty; -char name[20 ];struct ipoctal_channel *channel;struct ipack_region *region;void __iomem *addr;
@@ -355,8 +354,11 @@ static int ipoctal_inst_slot(struct ipoc/* Fill struct tty_driver with ipoctal data */ tty->owner =THIS_MODULE ; tty->driver_name =KBUILD_MODNAME ; -sprintf (name,KBUILD_MODNAME ".%d.%d." , bus_nr, slot); - tty->name = name; + tty->name =kasprintf (GFP_KERNEL ,KBUILD_MODNAME ".%d.%d." , bus_nr, slot); +if (!tty->name) { + res = -ENOMEM ; + goto err_put_driver; + } tty->major =0 ; tty->minor_start =0 ;
@@ -372,8 +374,7 @@ static int ipoctal_inst_slot(struct ipoc res =tty_register_driver (tty);if (res) {dev_err (&ipoctal->dev->dev,"Can't register tty driver.\n" ); -put_tty_driver (tty); -return res; + goto err_free_name; }/* Save struct tty_driver for use it when uninstalling the device */
@@ -410,6 +411,13 @@ static int ipoctal_inst_slot(struct ipoc ipoctal_irq_handler, ipoctal);return 0 ; + +err_free_name: +kfree (tty->name); +err_put_driver: +put_tty_driver (tty); + +return res; } static inline int ipoctal_copy_write_buffer(struct ipoctal_channel *channel,
@@ -697,6 +705,7 @@ static void __ipoctal_remove(struct ipoc }tty_unregister_driver (ipoctal->tty_drv); +kfree (ipoctal->tty_drv->name);put_tty_driver (ipoctal->tty_drv);kfree (ipoctal); }
Greg Kroah-Hartman
maintainerPATCH 149/172 ipack: ipoctal: fix tty registration race
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 65c001df517a7bf9be8621b53d43c89f426ce8d6 upstream.
Make sure to set the tty class-device driver data before registering the tty to avoid having a racing open() dereference a NULL pointer.
--- drivers/ipack/devices/ipoctal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ipack/devices/ipoctal.c +2 -2
@@ -393,13 +393,13 @@ static int ipoctal_inst_slot(struct ipocspin_lock_init (&channel->lock); channel->pointer_read =0 ; channel->pointer_write =0 ; - tty_dev =tty_port_register_device (&channel->tty_port, tty, i,NULL ); + tty_dev =tty_port_register_device_attr (&channel->tty_port, tty, + i,NULL , channel,NULL );if (IS_ERR (tty_dev)) {dev_err (&ipoctal->dev->dev,"Failed to register tty device.\n" );tty_port_destroy (&channel->tty_port);continue ; } -dev_set_drvdata (tty_dev, channel); }/*
Greg Kroah-Hartman
maintainerPATCH 150/172 ipack: ipoctal: fix tty-registration error handling
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit cd20d59291d1790dc74248476e928f57fc455189 upstream.
Registration of the ipoctal tty devices is unlikely to fail, but if it ever does, make sure not to deregister a never registered tty device (and dereference a NULL pointer) when the driver is later unbound.
--- drivers/ipack/devices/ipoctal.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/ipack/devices/ipoctal.c +7 -0
@@ -33,6 +33,7 @@ struct ipoctal_channel {unsigned int pointer_read;unsigned int pointer_write;struct tty_port tty_port; +bool tty_registered;union scc2698_channel __iomem *regs;union scc2698_block __iomem *block_regs;unsigned int board_id;
@@ -397,9 +398,11 @@ static int ipoctal_inst_slot(struct ipoc i, NULL, channel, NULL);if (IS_ERR (tty_dev)) {dev_err (&ipoctal->dev->dev,"Failed to register tty device.\n" ); +tty_port_free_xmit_buf (&channel->tty_port);tty_port_destroy (&channel->tty_port);continue ; } + channel->tty_registered = true; }/*
@@ -699,6 +702,10 @@ static void __ipoctal_remove(struct ipocfor (i =0 ; i <NR_CHANNELS ; i++) {struct ipoctal_channel *channel = &ipoctal->channel[i]; + +if (!channel->tty_registered) +continue ; +tty_unregister_device (ipoctal->tty_drv, i);tty_port_free_xmit_buf (&channel->tty_port);tty_port_destroy (&channel->tty_port);
Greg Kroah-Hartman
maintainerPATCH 151/172 ipack: ipoctal: fix missing allocation-failure check
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 445c8132727728dc297492a7d9fc074af3e94ba3 upstream.
Add the missing error handling when allocating the transmit buffer to avoid dereferencing a NULL pointer in write() should the allocation ever fail.
--- drivers/ipack/devices/ipoctal.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/ipack/devices/ipoctal.c +3 -1
@@ -386,7 +386,9 @@ static int ipoctal_inst_slot(struct ipoc channel = &ipoctal->channel[i];tty_port_init (&channel->tty_port); -tty_port_alloc_xmit_buf (&channel->tty_port); + res =tty_port_alloc_xmit_buf (&channel->tty_port); +if (res) +continue ; channel->tty_port.ops = &ipoctal_tty_port_ops;ipoctal_reset_stats (&channel->stats);
Greg Kroah-Hartman
maintainerPATCH 152/172 ipack: ipoctal: fix module reference leak
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit bb8a4fcb2136508224c596a7e665bdba1d7c3c27 upstream.
A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped.
Fix this by taking the module reference and initialising the tty driver data when installing the tty.
--- drivers/ipack/devices/ipoctal.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-)
drivers/ipack/devices/ipoctal.c +21 -8
@@ -82,22 +82,34 @@ static int ipoctal_port_activate(structreturn 0 ; } -static int ipoctal_open (struct tty_struct *tty,struct file *file) +static int ipoctal_install (struct tty_driver *driver,struct tty_struct *tty) {struct ipoctal_channel *channel =dev_get_drvdata (tty->dev);struct ipoctal *ipoctal =chan_to_ipoctal (channel, tty->index); -int err; - - tty->driver_data = channel; +int res;if (!ipack_get_carrier (ipoctal->dev))return -EBUSY ; - err =tty_port_open (&channel->tty_port, tty, file); -if (err) -ipack_put_carrier (ipoctal->dev); + res =tty_standard_install (driver, tty); +if (res) + goto err_put_carrier; + + tty->driver_data = channel; + +return 0 ; + +err_put_carrier: +ipack_put_carrier (ipoctal->dev); + +return res; +} + +static int ipoctal_open (struct tty_struct *tty,struct file *file) +{ +struct ipoctal_channel *channel = tty->driver_data; -return err; +return tty_port_open (&channel->tty_port, tty, file); }static void ipoctal_reset_stats (struct ipoctal_stats *stats)
@@ -662,6 +674,7 @@ static void ipoctal_cleanup(struct tty_sstatic const struct tty_operations ipoctal_fops = { .ioctl =NULL , + .install = ipoctal_install, .open = ipoctal_open, .close = ipoctal_close, .write = ipoctal_write_tty,
Greg Kroah-Hartman
maintainerPATCH 153/172 ext4: fix loff_t overflow in ext4_max_bitmap_size()
In reply to Greg Kroah-HartmanFrom: Ritesh Harjani <[email protected]>
commit 75ca6ad408f459f00b09a64f04c774559848c097 upstream.
We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true)
Below is a quick test to trigger it on a 64KB pagesize system.
sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt
sudo echo "hello" > /mnt/hello -> This will error out with
"echo: write error: File too large"
--- fs/ext4/super.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
fs/ext4/super.c +5 -5
@@ -3185,17 +3185,17 @@ static loff_t ext4_max_size(int blkbits,*/ static loff_t ext4_max_bitmap_size (int bits,int has_huge_files) { -loff_t res =EXT4_NDIR_BLOCKS ; +unsigned long long upper_limit, res =EXT4_NDIR_BLOCKS ;int meta_blocks; -loff_t upper_limit; -/* This is calculated to be the largest file size for a dense, block + +/* +* This is calculated to be the largest file size for a dense, block * mapped file such that the file's total number of 512-byte sectors, * including data and all indirect blocks, does not exceed (2^48 - 1). * * __u32 i_blocks_lo and _u16 i_blocks_high represent the total * number of 512-byte sectors of the file. */ -if (!has_huge_files) {/* * !has_huge_files or implies that the inode i_block field
@@ -3238,7 +3238,7 @@ static loff_t ext4_max_bitmap_size(int bif (res >MAX_LFS_FILESIZE ) res =MAX_LFS_FILESIZE ; -return res; +return (loff_t )res; } static ext4_fsblk_t descriptor_loc(struct super_block *sb,
Greg Kroah-Hartman
maintainerPATCH 154/172 ext4: limit the number of blocks in one ADD_RANGE TLV
In reply to Greg Kroah-HartmanFrom: Hou Tao <[email protected]>
commit a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6 upstream.
Now EXT4_FC_TAG_ADD_RANGE uses ext4_extent to track the newly-added blocks, but the limit on the max value of ee_len field is ignored, and it can lead to BUG_ON as shown below when running command "fallocate -l 128M file" on a fast_commit-enabled fs:
kernel BUG at fs/ext4/ext4_extents.h:199! invalid opcode: 0000 [#1] SMP PTI
CPU: 3 PID: 624 Comm: fallocate Not tainted 5.14.0-rc6+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:ext4_fc_write_inode_data+0x1f3/0x200 Call Trace: ? ext4_fc_write_inode+0xf2/0x150 ext4_fc_commit+0x93b/0xa00 ? ext4_fallocate+0x1ad/0x10d0 ext4_sync_file+0x157/0x340 ? ext4_sync_file+0x157/0x340 vfs_fsync_range+0x49/0x80 do_fsync+0x3d/0x70 __x64_sys_fsync+0x14/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Simply fixing it by limiting the number of blocks in one EXT4_FC_TAG_ADD_RANGE TLV.
--- fs/ext4/fast_commit.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/ext4/fast_commit.c +6 -0
@@ -893,6 +893,12 @@ static int ext4_fc_write_inode_data(stru sizeof(lrange), (u8 *)&lrange, crc))return -ENOSPC ; }else { +unsigned int max = (map.m_flags &EXT4_MAP_UNWRITTEN ) ? +EXT_UNWRITTEN_MAX_LEN :EXT_INIT_MAX_LEN ; + +/* Limit the number of blocks in one extent */ + map.m_len =min (max, map.m_len); + fc_ext.fc_ino =cpu_to_le32 (inode->i_ino); ex = (struct ext4_extent *)&fc_ext.fc_ex; ex->ee_block =cpu_to_le32 (map.m_lblk);
Greg Kroah-Hartman
maintainerPATCH 155/172 ext4: fix reserved space counter leakage
In reply to Greg Kroah-HartmanFrom: Jeffle Xu <[email protected]>
commit 6fed83957f21eff11c8496e9f24253b03d2bc1dc upstream.
When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space.
Another effect of this bug is that /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem.
Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode().
--- fs/ext4/inode.c | 5 +++++ fs/ext4/super.c | 6 ++++++ 2 files changed, 11 insertions(+)
fs/ext4/inode.c +5 -0
@@ -1640,6 +1640,7 @@ static int ext4_insert_delayed_block(strstruct ext4_sb_info *sbi =EXT4_SB (inode->i_sb);int ret;bool allocated = false; +bool reserved = false;/* * If the cluster containing lblk is shared with a delayed,
@@ -1656,6 +1657,7 @@ static int ext4_insert_delayed_block(str ret =ext4_da_reserve_space (inode);if (ret !=0 )/* ENOSPC */ goto errout; + reserved = true; } else { /* bigalloc */ if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) { if (!ext4_es_scan_clu(inode,
@@ -1668,6 +1670,7 @@ static int ext4_insert_delayed_block(str ret =ext4_da_reserve_space (inode);if (ret !=0 )/* ENOSPC */ goto errout; + reserved = true; }else { allocated = true; }
@@ -1678,6 +1681,8 @@ static int ext4_insert_delayed_block(str } ret =ext4_es_insert_delayed_block (inode, lblk, allocated); +if (ret && reserved) +ext4_da_release_space (inode,1 ); errout:return ret;
fs/ext4/super.c +6 -0
@@ -1351,6 +1351,12 @@ static void ext4_destroy_inode(struct in true);dump_stack (); } + +if (EXT4_I (inode)->i_reserved_data_blocks) +ext4_msg (inode->i_sb,KERN_ERR , +"Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!" , + inode->i_ino,EXT4_I (inode), +EXT4_I (inode)->i_reserved_data_blocks); }static void init_once (void *foo)
Greg Kroah-Hartman
maintainerPATCH 156/172 ext4: add error checking to ext4_ext_replay_set_iblocks()
In reply to Greg Kroah-HartmanFrom: Theodore Ts'o <[email protected]>
commit 1fd95c05d8f742abfe906620780aee4dbe1a2db0 upstream.
If the call to ext4_map_blocks() fails due to an corrupted file system, ext4_ext_replay_set_iblocks() can get stuck in an infinite loop. This could be reproduced by running generic/526 with a file system that has inline_data and fast_commit enabled. The system will repeatedly log to the console:
EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 > max in inode 131076
and the stack that it gets stuck in is:
ext4_block_to_path+0xe3/0x130 ext4_ind_map_blocks+0x93/0x690 ext4_map_blocks+0x100/0x660 skip_hole+0x47/0x70 ext4_ext_replay_set_iblocks+0x223/0x440 ext4_fc_replay_inode+0x29e/0x3b0 ext4_fc_replay+0x278/0x550 do_one_pass+0x646/0xc10 jbd2_journal_recover+0x14a/0x270 jbd2_journal_load+0xc4/0x150 ext4_load_journal+0x1f3/0x490 ext4_fill_super+0x22d4/0x2c00
With this patch, generic/526 still fails, but system is no longer locking up in a tight loop. It's likely the root casue is that fast_commit replay is corrupting file systems with inline_data, and we probably need to add better error handling in the fast commit replay code path beyond what is done here, which essentially just breaks the infinite loop without reporting the to the higher levels of the code.
--- fs/ext4/extents.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
fs/ext4/extents.c +14 -5
@@ -5908,7 +5908,7 @@ void ext4_ext_replay_shrink_inode(struct }/* Check if *cur is a hole and if it is, skip it */ -static void skip_hole (struct inode *inode,ext4_lblk_t *cur) +static int skip_hole (struct inode *inode,ext4_lblk_t *cur) {int ret;struct ext4_map_blocks map;
@@ -5917,9 +5917,12 @@ static void skip_hole(struct inode *inod map.m_len = ((inode->i_size) >> inode->i_sb->s_blocksize_bits) - *cur; ret =ext4_map_blocks (NULL , inode, &map,0 ); +if (ret <0 ) +return ret;if (ret !=0 ) -return ; +return 0 ; *cur = *cur + map.m_len; +return 0 ; }/* Count number of blocks used by this inode and update i_blocks */
@@ -5968,7 +5971,9 @@ int ext4_ext_replay_set_iblocks(struct i* iblocks by total number of differences found. */ cur =0 ; -skip_hole (inode, &cur); + ret =skip_hole (inode, &cur); +if (ret <0 ) + goto out; path =ext4_find_extent (inode, cur,NULL ,0 );if (IS_ERR (path)) goto out;
@@ -5987,8 +5992,12 @@ int ext4_ext_replay_set_iblocks(struct i } cur =max (cur +1 ,le32_to_cpu (ex->ee_block) +ext4_ext_get_actual_len (ex)); -skip_hole (inode, &cur); - + ret =skip_hole (inode, &cur); +if (ret <0 ) { +ext4_ext_drop_refs (path); +kfree (path); +break ; + } path2 =ext4_find_extent (inode, cur,NULL ,0 );if (IS_ERR (path2)) {ext4_ext_drop_refs (path);
Greg Kroah-Hartman
maintainerPATCH 157/172 ext4: fix potential infinite loop in ext4_dx_readdir()
In reply to Greg Kroah-HartmanFrom: yangerkun <[email protected]>
commit 42cb447410d024e9d54139ae9c21ea132a8c384c upstream.
When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an infinite loop since if info->last_pos != ctx->pos this will reset the directory scan and reread the failing entry. For example:
1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as leaf block which own the ext4_dir_entry_2
2. block 1 read ok and call_filldir which will fill the dirent and update the ctx->pos
3. block 2 read fail, but we has already fill some dirent, so we will return back to userspace will a positive return val(see ksys_getdents64)
4. the second ext4_dx_readdir will reset the world since info->last_pos != ctx->pos, and will also init the curr_hash which pos to block 1
5. So we will read block1 too, and once block2 still read fail, we can only fill one dirent because the hash of the entry in block1(besides the last one) won't greater than curr_hash
6. this time, we forget update last_pos too since the read for block2 will fail, and since we has got the one entry, ksys_getdents64 can return success
7. Latter we will trapped in a loop with step 4~6
--- fs/ext4/dir.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext4/dir.c +3 -3
@@ -551,7 +551,7 @@ static int ext4_dx_readdir(struct file *struct dir_private_info *info = file->private_data;struct inode *inode =file_inode (file);struct fname *fname; -int ret; +int ret =0 ;if (!info) { info =ext4_htree_create_dir_info (file, ctx->pos);
@@ -599,7 +599,7 @@ static int ext4_dx_readdir(struct file * info->curr_minor_hash, &info->next_hash);if (ret <0 ) -return ret; + goto finished;if (ret ==0 ) { ctx->pos =ext4_get_htree_eof (file);break ;
@@ -630,7 +630,7 @@ static int ext4_dx_readdir(struct file * } finished: info->last_pos = ctx->pos; -return 0 ; +return ret <0 ? ret :0 ; }static int ext4_release_dir (struct inode *inode,struct file *filp)
Greg Kroah-Hartman
maintainerPATCH 158/172 ext4: flush s_error_work before journal destroy in ext4_fill_super
In reply to Greg Kroah-HartmanFrom: yangerkun <[email protected]>
commit bb9464e08309f6befe80866f5be51778ca355ee9 upstream.
The error path in ext4_fill_super forget to flush s_error_work before journal destroy, and it may trigger the follow bug since flush_stashed_error_work can run concurrently with journal destroy without any protection for sbi->s_journal.
[32031.740193] EXT4-fs (loop66): get root inode failed [32031.740484] EXT4-fs (loop66): mount failed [32031.759805] ------------[ cut here ]------------ [32031.759807] kernel BUG at fs/jbd2/transaction.c:373! [32031.760075] invalid opcode: 0000 [#1] SMP PTI [32031.760336] CPU: 5 PID: 1029268 Comm: kworker/5:1 Kdump: loaded 4.18.0 [32031.765112] Call Trace: [32031.765375] ? __switch_to_asm+0x35/0x70 [32031.765635] ? __switch_to_asm+0x41/0x70 [32031.765893] ? __switch_to_asm+0x35/0x70 [32031.766148] ? __switch_to_asm+0x41/0x70 [32031.766405] ? _cond_resched+0x15/0x40 [32031.766665] jbd2__journal_start+0xf1/0x1f0 [jbd2] [32031.766934] jbd2_journal_start+0x19/0x20 [jbd2] [32031.767218] flush_stashed_error_work+0x30/0x90 [ext4] [32031.767487] process_one_work+0x195/0x390 [32031.767747] worker_thread+0x30/0x390 [32031.768007] ? process_one_work+0x390/0x390 [32031.768265] kthread+0x10d/0x130 [32031.768521] ? kthread_flush_work_fn+0x10/0x10 [32031.768778] ret_from_fork+0x35/0x40
static int start_this_handle(...)
BUG_ON(journal->j_flags & JBD2_UNMOUNT); <---- Trigger this
Besides, after we enable fast commit, ext4_fc_replay can add work to s_error_work but return success, so the latter journal destroy in ext4_load_journal can trigger this problem too.
Fix this problem with two steps:
1. Call ext4_commit_super directly in ext4_handle_error for the case that called from ext4_fc_replay
2. Since it's hard to pair the init and flush for s_error_work, we'd better add a extras flush_work before journal destroy in ext4_fill_super
Besides, this patch will call ext4_commit_super in ext4_handle_error for any nojournal case too. But it seems safe since the reason we call schedule_work was that we should save error info to sb through journal if available. Conversely, for the nojournal case, it seems useless delay commit superblock to s_error_work.
--- fs/ext4/super.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/ext4/super.c +4 -1
@@ -661,7 +661,7 @@ static void ext4_handle_error(struct sup* constraints, it may not be safe to do it right here so we * defer superblock flushing to a workqueue. */ -if (continue_fs) +if (continue_fs && journal)schedule_work (&EXT4_SB (sb)->s_error_work);else ext4_commit_super (sb);
@@ -5189,12 +5189,15 @@ failed_mount_wq: sbi->s_ea_block_cache =NULL ;if (sbi->s_journal) { +/* flush s_error_work before journal destroy. */ +flush_work (&sbi->s_error_work);jbd2_journal_destroy (sbi->s_journal); sbi->s_journal =NULL ; } failed_mount3a:ext4_es_unregister_shrinker (sbi); failed_mount3: +/* flush s_error_work before sbi destroy */ flush_work (&sbi->s_error_work);del_timer_sync (&sbi->s_err_report);ext4_stop_mmpd (sbi);
Greg Kroah-Hartman
maintainerPATCH 159/172 HID: u2fzero: ignore incomplete packets without data
In reply to Greg Kroah-HartmanFrom: Andrej Shadura <[email protected]>
commit 22d65765f211cc83186fd8b87521159f354c0da9 upstream.
Since the actual_length calculation is performed unsigned, packets shorter than 7 bytes (e.g. packets without data or otherwise truncated) or non-received packets ("zero" bytes) can cause buffer overflow.
--- drivers/hid/hid-u2fzero.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hid/hid-u2fzero.c +3 -1
@@ -198,7 +198,9 @@ static int u2fzero_rng_read(struct hwrng } ret =u2fzero_recv (dev, &req, &resp); -if (ret <0 ) + +/* ignore errors or packets without data */ + if (ret < offsetof(struct u2f_hid_msg, init.data))return 0 ;/* only take the minimum amount of data it is safe to take */
Greg Kroah-Hartman
maintainerPATCH 160/172 net: udp: annotate data race around udp_sk(sk)->corkflag
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit a9f5970767d11eadc805d5283f202612c7ba1f59 upstream.
up->corkflag field can be read or written without any lock. Annotate accesses to avoid possible syzbot/KCSAN reports.
--- net/ipv4/udp.c | 10 +++++----- net/ipv6/udp.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-)
net/ipv4/udp.c +5 -5
@@ -1053,7 +1053,7 @@ int udp_sendmsg(struct sock *sk, struct__be16 dport;u8 tos;int err, is_udplite =IS_UDPLITE (sk); -int corkreq = up->corkflag || msg->msg_flags&MSG_MORE ; +int corkreq =READ_ONCE (up->corkflag) || msg->msg_flags&MSG_MORE ;int (*getfrag)(void *,char *,int ,int ,int ,struct sk_buff *);struct sk_buff *skb;struct ip_options_data opt_copy;
@@ -1361,7 +1361,7 @@ int udp_sendpage(struct sock *sk, struct } up->len += size; -if (!(up->corkflag || (flags&MSG_MORE ))) +if (!(READ_ONCE (up->corkflag) || (flags&MSG_MORE ))) ret =udp_push_pending_frames (sk);if (!ret) ret = size;
@@ -2662,9 +2662,9 @@ int udp_lib_setsockopt(struct sock *sk,switch (optname) {case UDP_CORK :if (val !=0 ) { - up->corkflag =1 ; +WRITE_ONCE (up->corkflag,1 ); }else { - up->corkflag =0 ; +WRITE_ONCE (up->corkflag,0 );lock_sock (sk);push_pending_frames (sk);release_sock (sk);
@@ -2787,7 +2787,7 @@ int udp_lib_getsockopt(struct sock *sk,switch (optname) {case UDP_CORK : - val = up->corkflag; + val =READ_ONCE (up->corkflag);break ;case UDP_ENCAP :
net/ipv6/udp.c +1 -1
@@ -1303,7 +1303,7 @@ int udpv6_sendmsg(struct sock *sk, strucint addr_len = msg->msg_namelen;bool connected = false;int ulen = len; -int corkreq = up->corkflag || msg->msg_flags&MSG_MORE ; +int corkreq =READ_ONCE (up->corkflag) || msg->msg_flags&MSG_MORE ;int err;int is_udplite =IS_UDPLITE (sk);int (*getfrag)(void *,char *,int ,int ,int ,struct sk_buff *);
Greg Kroah-Hartman
maintainerPATCH 161/172 NIOS2: setup.c: drop unused variable dram_start
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
commit 9523b33cc31cf8ce703f8facee9fd16cba36d5ad upstream.
This is a nuisance when CONFIG_WERROR is set, so drop the variable declaration since the code that used it was removed.
../arch/nios2/kernel/setup.c: In function 'setup_arch':../arch/nios2/kernel/setup.c:152:13: warning: unused variable 'dram_start' [-Wunused-variable]
152 | int dram_start;
--- arch/nios2/kernel/setup.c | 2 -- 1 file changed, 2 deletions(-)
arch/nios2/kernel/setup.c +0 -2
@@ -149,8 +149,6 @@ static void __init find_limits(unsignedvoid __init setup_arch (char **cmdline_p) { -int dram_start; -console_verbose (); memory_start =memblock_start_of_DRAM ();
Greg Kroah-Hartman
maintainerPATCH 162/172 usb: hso: remove the bailout parameter
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
commit dcb713d53e2eadf42b878c12a471e74dc6ed3145 upstream.
There are two invocation sites of hso_free_net_device. After refactoring hso_create_net_device, this parameter is useless. Remove the bailout in the hso_free_net_device and change the invocation sites of this function.
[Backport this cleanup patch to 5.10 and 5.14 in order to keep the codebase consistent with the 4.14/4.19/5.4 patchseries]
--- drivers/net/usb/hso.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/usb/hso.c +3 -3
@@ -2353,7 +2353,7 @@ static int remove_net_device(struct hso_ }/* Frees our network device */ -static void hso_free_net_device (struct hso_device *hso_dev,bool bailout) +static void hso_free_net_device (struct hso_device *hso_dev) {int i;struct hso_net *hso_net =dev2net (hso_dev);
@@ -2376,7 +2376,7 @@ static void hso_free_net_device(struct hkfree (hso_net->mux_bulk_tx_buf); hso_net->mux_bulk_tx_buf =NULL ; -if (hso_net->net && !bailout) +if (hso_net->net)free_netdev (hso_net->net);kfree (hso_dev);
@@ -3136,7 +3136,7 @@ static void hso_free_interface(struct usrfkill_unregister (rfk);rfkill_destroy (rfk); } -hso_free_net_device (network_table[i], false); +hso_free_net_device (network_table[i]); } } }
Greg Kroah-Hartman
maintainerPATCH 163/172 HID: betop: fix slab-out-of-bounds Write in betop_probe
In reply to Greg Kroah-HartmanFrom: F.A.Sulaiman <[email protected]>
commit 1e4ce418b1cb1a810256b5fb3fd33d22d1325993 upstream.
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption.
So this patch checks hid_device's input is non empty before it's been used.
--- drivers/hid/hid-betopff.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/hid/hid-betopff.c +10 -3
@@ -56,15 +56,22 @@ static int betopff_init(struct hid_devic {struct betopff_device *betopff;struct hid_report *report; -struct hid_input *hidinput = - list_first_entry(&hid->inputs, struct hid_input, list); +struct hid_input *hidinput;struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT ].report_list; -struct input_dev *dev = hidinput->input; +struct input_dev *dev;int field_count =0 ;int error;int i, j; +if (list_empty (&hid->inputs)) { +hid_err (hid,"no inputs found\n" ); +return -ENODEV ; + } + + hidinput = list_first_entry(&hid->inputs, struct hid_input, list); + dev = hidinput->input; +if (list_empty (report_list)) {hid_err (hid,"no output reports found\n" );return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 164/172 netfilter: ipset: Fix oversized kvmalloc() calls
In reply to Greg Kroah-HartmanFrom: Jozsef Kadlecsik <[email protected]>
commit 7bbc3d385bd813077acaf0e6fdb2a86a901f5382 upstream.
The commit
commit 7661809d493b426e979f39ab512e3adf41fbcc69
Author: Linus Torvalds <[email protected]> Date: Wed Jul 14 09:45:49 2021 -0700
mm: don't allow oversized kvmalloc() calls
limits the max allocatable memory via kvmalloc() to MAX_INT. Apply the same limit in ipset.
--- net/netfilter/ipset/ip_set_hash_gen.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/ipset/ip_set_hash_gen.h +2 -2
@@ -130,11 +130,11 @@ htable_size(u8 hbits) {size_t hsize; -/* We must fit both into u32 in jhash and size_t */ +/* We must fit both into u32 in jhash and INT_MAX in kvmalloc_node() */ if (hbits >31 )return 0 ; hsize =jhash_size (hbits); -if ((((size_t )-1 ) -sizeof (struct htable )) /sizeof (struct hbucket *) +if ((INT_MAX -sizeof (struct htable )) /sizeof (struct hbucket *) < hsize)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 165/172 mm: dont allow oversized kvmalloc() calls
In reply to Greg Kroah-HartmanFrom: Linus Torvalds <[email protected]>
commit 7661809d493b426e979f39ab512e3adf41fbcc69 upstream.
'kvmalloc()' is a convenience function for people who want to do a kmalloc() but fall back on vmalloc() if there aren't enough physically contiguous pages, or if the allocation is larger than what kmalloc() supports.
However, let's make sure it doesn't get _too_ easy to do crazy things with it. In particular, don't allow big allocations that could be due to integer overflow or underflow. So make sure the allocation size fits in an 'int', to protect against trivial integer conversion issues.
--- mm/util.c | 4 ++++ 1 file changed, 4 insertions(+)
mm/util.c +4 -0
@@ -593,6 +593,10 @@ void *kvmalloc_node(size_t size, gfp_t fif (ret || size <=PAGE_SIZE )return ret; +/* Don't even allow crazy sizes */ +if (WARN_ON_ONCE (size >INT_MAX )) +return NULL ; +return __vmalloc_node (size,1 , flags, node,__builtin_return_address (0 )); }
Greg Kroah-Hartman
maintainerPATCH 166/172 HID: usbhid: free raw_report buffers in usbhid_stop
In reply to Greg Kroah-HartmanFrom: Anirudh Rayabharam <[email protected]>
commit f7744fa16b96da57187dc8e5634152d3b63d72de upstream.
Free the unsent raw_report buffers when the device is removed.
Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47
--- drivers/hid/usbhid/hid-core.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/hid/usbhid/hid-core.c +12 -1
@@ -505,7 +505,7 @@ static void hid_ctrl(struct urb *urb)if (unplug) { usbhid->ctrltail = usbhid->ctrlhead; - }else { + }else if (usbhid->ctrlhead != usbhid->ctrltail) { usbhid->ctrltail = (usbhid->ctrltail +1 ) & (HID_CONTROL_FIFO_SIZE -1 ); if (usbhid->ctrlhead != usbhid->ctrltail &&
@@ -1223,9 +1223,20 @@ static void usbhid_stop(struct hid_devicmutex_lock (&usbhid->mutex);clear_bit (HID_STARTED , &usbhid->iofl); +spin_lock_irq (&usbhid->lock);/* Sync with error and led handlers */ set_bit (HID_DISCONNECTED , &usbhid->iofl); +while (usbhid->ctrltail != usbhid->ctrlhead) { +if (usbhid->ctrl[usbhid->ctrltail].dir ==USB_DIR_OUT ) { +kfree (usbhid->ctrl[usbhid->ctrltail].raw_report); + usbhid->ctrl[usbhid->ctrltail].raw_report =NULL ; + } + + usbhid->ctrltail = (usbhid->ctrltail +1 ) & + (HID_CONTROL_FIFO_SIZE -1 ); + }spin_unlock_irq (&usbhid->lock); +usb_kill_urb (usbhid->urbin);usb_kill_urb (usbhid->urbout);usb_kill_urb (usbhid->urbctrl);
Greg Kroah-Hartman
maintainerPATCH 167/172 crypto: aesni - xts_crypt() return if walk.nbytes is 0
In reply to Greg Kroah-HartmanFrom: Shreyansh Chouhan <[email protected]>
commit 72ff2bf04db2a48840df93a461b7115900f46c05 upstream.
xts_crypt() code doesn't call kernel_fpu_end() after calling kernel_fpu_begin() if walk.nbytes is 0. The correct behavior should be not calling kernel_fpu_begin() if walk.nbytes is 0.
--- arch/x86/crypto/aesni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/crypto/aesni-intel_glue.c +1 -1
@@ -849,7 +849,7 @@ static int xts_crypt(struct skcipher_reqreturn -EINVAL ; err =skcipher_walk_virt (&walk, req, false); -if (err) +if (!walk.nbytes)return err;if (unlikely (tail >0 && walk.nbytes < walk.total)) {
Greg Kroah-Hartman
maintainerPATCH 168/172 net: mdiobus: Fix memory leak in __mdiobus_register
In reply to Greg Kroah-HartmanFrom: Yanfei Xu <[email protected]>
commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.
Once device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it will cause memory leak.
BUG: memory leak
unreferenced object 0xffff888114032e00 (size 256):
comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff ................
08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff .........ve.....
backtrace:
[<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
[<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
[<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
[<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
[<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
[<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
[<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
[<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
[<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
[<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
[<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
[<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
[<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
[<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
[<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
[<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
[<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
[<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
[<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
BUG: memory leak
unreferenced object 0xffff888116f06900 (size 32):
comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
hex dump (first 32 bytes):
75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00 usb-001:003.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
[<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
[<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
[<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
[<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
[<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
[<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
[<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
[<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
[<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
[<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
[<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
[<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
[<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
[<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
[<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
[<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969--- drivers/net/phy/mdio_bus.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/phy/mdio_bus.c +1 -0
@@ -541,6 +541,7 @@ int __mdiobus_register(struct mii_bus *b err =device_register (&bus->dev);if (err) {pr_err ("mii_bus %s failed to register\n" , bus->id); +put_device (&bus->dev);return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 169/172 KVM: x86: Handle SRCU initialization failure during page track init
In reply to Greg Kroah-HartmanFrom: Haimin Zhang <[email protected]>
commit eb7511bf9182292ef1df1082d23039e856d1ddfb upstream.
Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller.
Message-Id: <[email protected]>
--- arch/x86/include/asm/kvm_page_track.h | 2 +- arch/x86/kvm/mmu/page_track.c | 4 ++-- arch/x86/kvm/x86.c | 7 ++++++- 3 files changed, 9 insertions(+), 4 deletions(-)
arch/x86/include/asm/kvm_page_track.h +1 -1
@@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node { struct kvm_page_track_notifier_node *node); }; -void kvm_page_track_init (struct kvm *kvm); +int kvm_page_track_init (struct kvm *kvm);void kvm_page_track_cleanup (struct kvm *kvm);void kvm_page_track_free_memslot (struct kvm_memory_slot *slot);
arch/x86/kvm/mmu/page_track.c +2 -2
@@ -163,13 +163,13 @@ void kvm_page_track_cleanup(struct kvm *cleanup_srcu_struct (&head->track_srcu); } -void kvm_page_track_init (struct kvm *kvm) +int kvm_page_track_init (struct kvm *kvm) {struct kvm_page_track_notifier_head *head; head = &kvm->arch.track_notifier_head; -init_srcu_struct (&head->track_srcu);INIT_HLIST_HEAD (&head->track_notifier_list); +return init_srcu_struct (&head->track_srcu); }/*
arch/x86/kvm/x86.c +6 -1
@@ -11093,9 +11093,15 @@ void kvm_arch_free_vm(struct kvm *kvm)int kvm_arch_init_vm (struct kvm *kvm,unsigned long type) { +int ret; +if (type)return -EINVAL ; + ret =kvm_page_track_init (kvm); +if (ret) +return ret; +INIT_HLIST_HEAD (&kvm->arch.mask_notifier_list);INIT_LIST_HEAD (&kvm->arch.active_mmu_pages);INIT_LIST_HEAD (&kvm->arch.zapped_obsolete_pages);
@@ -11128,7 +11134,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unkvm_apicv_init (kvm);kvm_hv_init_vm (kvm); -kvm_page_track_init (kvm);kvm_mmu_init_vm (kvm);return static_call (kvm_x86_vm_init)(kvm);
Greg Kroah-Hartman
maintainerPATCH 170/172 netfilter: conntrack: serialize hash resizes and cleanups
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit e9edc188fc76499b0b9bd60364084037f6d03773 upstream.
Syzbot was able to trigger the following warning [1]
No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and:
for j in seq 1 1000 ; do unshare -n /bin/true >/dev/null ; done
It would take more than 5 minutes for net_namespace structures to be cleaned up.
This is because nf_ct_iterate_cleanup() has to restart everytime a resize happened.
By adding a mutex, we can serialize hash resizes and cleanups and also make get_next_corpse() faster by skipping over empty buckets.
Even without resizes in the picture, this patch considerably speeds up network namespace dismantles.
[1]
INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006
Call Trace:
context_switch kernel/sched/core.c:4955 [inline]
__schedule+0x940/0x26f0 kernel/sched/core.c:6236
preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
__local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
local_bh_enable include/linux/bottom_half.h:32 [inline]
get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
setup_net+0x639/0xa30 net/core/net_namespace.c:349
copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
ksys_unshare+0x445/0x920 kernel/fork.c:3128
__do_sys_unshare kernel/fork.c:3202 [inline]
__se_sys_unshare kernel/fork.c:3200 [inline]
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f63da68e739
RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000
Showing all locks held in the system:
1 lock held by khungtaskd/27:
#0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
2 locks held by kworker/u4:2/153:
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
#1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
1 lock held by systemd-udevd/2970:
1 lock held by in:imklog/6258:
#0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
3 locks held by kworker/1:6/8158:
1 lock held by syz-executor.0/8312:
2 locks held by kworker/u4:13/9320:
1 lock held by syz-executor.5/10178:
1 lock held by syz-executor.4/10217:--- net/netfilter/nf_conntrack_core.c | 70 ++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 33 deletions(-)
net/netfilter/nf_conntrack_core.c +37 -33
@@ -75,6 +75,9 @@ static __read_mostly struct kmem_cache *static DEFINE_SPINLOCK (nf_conntrack_locks_all_lock);static __read_mostly bool nf_conntrack_locks_all; +/* serialize hash resizes and nf_ct_iterate_cleanup */ +static DEFINE_MUTEX (nf_conntrack_mutex); +#define GC_SCAN_INTERVAL (120u * HZ)#define GC_SCAN_MAX_DURATION msecs_to_jiffies(10)
@@ -2192,28 +2195,31 @@ get_next_corpse(int (*iter)(struct nf_cospinlock_t *lockp;for (; *bucket < nf_conntrack_htable_size; (*bucket)++) { +struct hlist_nulls_head *hslot = &nf_conntrack_hash[*bucket]; + +if (hlist_nulls_empty (hslot)) +continue ; + lockp = &nf_conntrack_locks[*bucket %CONNTRACK_LOCKS ];local_bh_disable ();nf_conntrack_lock (lockp); -if (*bucket < nf_conntrack_htable_size) { -hlist_nulls_for_each_entry (h, n, &nf_conntrack_hash[*bucket], hnnode) { -if (NF_CT_DIRECTION (h) !=IP_CT_DIR_REPLY ) -continue ; -/* All nf_conn objects are added to hash table twice, one -* for original direction tuple, once for the reply tuple. -* -* Exception: In the IPS_NAT_CLASH case, only the reply -* tuple is added (the original tuple already existed for -* a different object). -* -* We only need to call the iterator once for each -* conntrack, so we just use the 'reply' direction -* tuple while iterating. -*/ - ct =nf_ct_tuplehash_to_ctrack (h); -if (iter (ct, data)) - goto found; - } +hlist_nulls_for_each_entry (h, n, hslot, hnnode) { +if (NF_CT_DIRECTION (h) !=IP_CT_DIR_REPLY ) +continue ; +/* All nf_conn objects are added to hash table twice, one +* for original direction tuple, once for the reply tuple. +* +* Exception: In the IPS_NAT_CLASH case, only the reply +* tuple is added (the original tuple already existed for +* a different object). +* +* We only need to call the iterator once for each +* conntrack, so we just use the 'reply' direction +* tuple while iterating. +*/ + ct =nf_ct_tuplehash_to_ctrack (h); +if (iter (ct, data)) + goto found; }spin_unlock (lockp);local_bh_enable ();
@@ -2231,26 +2237,20 @@ found:static void nf_ct_iterate_cleanup (int (*iter)(struct nf_conn *i,void *data),void *data,u32 portid,int report) { -unsigned int bucket =0 , sequence; +unsigned int bucket =0 ;struct nf_conn *ct;might_sleep (); -for (;;) { - sequence =read_seqcount_begin (&nf_conntrack_generation); - -while ((ct =get_next_corpse (iter, data, &bucket)) !=NULL ) { -/* Time to push up daises... */ +mutex_lock (&nf_conntrack_mutex); +while ((ct =get_next_corpse (iter, data, &bucket)) !=NULL ) { +/* Time to push up daises... */ -nf_ct_delete (ct, portid, report); -nf_ct_put (ct); -cond_resched (); - } - -if (!read_seqcount_retry (&nf_conntrack_generation, sequence)) -break ; - bucket =0 ; +nf_ct_delete (ct, portid, report); +nf_ct_put (ct); +cond_resched (); } +mutex_unlock (&nf_conntrack_mutex); }struct iter_data {
@@ -2486,8 +2486,10 @@ int nf_conntrack_hash_resize(unsigned inif (!hash)return -ENOMEM ; +mutex_lock (&nf_conntrack_mutex); old_size = nf_conntrack_htable_size;if (old_size == hashsize) { +mutex_unlock (&nf_conntrack_mutex);kvfree (hash);return 0 ; }
@@ -2523,6 +2525,8 @@ int nf_conntrack_hash_resize(unsigned innf_conntrack_all_unlock ();local_bh_enable (); +mutex_unlock (&nf_conntrack_mutex); +synchronize_net ();kvfree (old_hash);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 171/172 netfilter: nf_tables: Fix oversized kvmalloc() calls
In reply to Greg Kroah-HartmanFrom: Pablo Neira Ayuso <[email protected]>
commit 45928afe94a094bcda9af858b96673d59bc4a0e9 upstream.
The commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") limits the max allocatable memory via kvmalloc() to MAX_INT.
--- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/nf_tables_api.c +1 -1
@@ -4336,7 +4336,7 @@ static int nf_tables_newset(struct sk_buif (ops->privsize !=NULL ) size = ops->privsize (nla, &desc); alloc_size =sizeof (*set) + size + udlen; -if (alloc_size < size) +if (alloc_size < size || alloc_size >INT_MAX )return -ENOMEM ; set =kvzalloc (alloc_size,GFP_KERNEL );if (!set)
Greg Kroah-Hartman
maintainerPATCH 172/172 drivers: net: mhi: fix error path in mhi_net_newlink
In reply to Greg Kroah-HartmanFrom: Daniele Palmas <[email protected]>
commit 4526fe74c3c5095cc55931a3a6fb4932f9e06002 upstream.
Fix double free_netdev when mhi_prepare_for_transfer fails.
--- drivers/net/mhi/net.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/net/mhi/net.c +2 -4
@@ -337,7 +337,7 @@ static int mhi_net_newlink(void *ctxt, s/* Start MHI channels */ err =mhi_prepare_for_transfer (mhi_dev);if (err) - goto out_err; +return err;/* Number of transfer descriptors determines size of the queue */ mhi_netdev->rx_queue_sz =mhi_get_free_desc_count (mhi_dev,DMA_FROM_DEVICE );
@@ -347,7 +347,7 @@ static int mhi_net_newlink(void *ctxt, selse err =register_netdev (ndev);if (err) - goto out_err; +return err;if (mhi_netdev->proto) { err = mhi_netdev->proto->init (mhi_netdev);
@@ -359,8 +359,6 @@ static int mhi_net_newlink(void *ctxt, s out_err_proto:unregister_netdevice (ndev); -out_err: -free_netdev (ndev);return err; }
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 10 lines · Pavel Machek
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Sorry, I replied to wrong email. We are not actually testing 5.14.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
5.14.10-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Similar to other comments., this commit:
net: mdiobus: Fix memory leak in __mdiobus_register
has since been reverted upstream. Thanks!
Signature · 1 line
Florian
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 480 pass: 480 fail: 0
Guenter
Quoted 6 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines
Quoted 3 lines
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 480 pass: 480 fail: 0
I spoke too early. A large number of boot tests report the following warning tracebacks in this rc.
Guenter
====================================
WARNING: ip/134 still has locks held! 5.14.10-rc1-00173-gcda15f9c69e0 #1 Not tainted
------------------------------------
1 lock held by ip/134:
#0: c17acf0c (sk_lock-AF_INET){+.+.}-{0:0}, at: 0xc17c561c
stack backtrace: CPU: 0 PID: 134 Comm: ip Not tainted 5.14.10-rc1-00173-gcda15f9c69e0 #1 Call trace: [<(ptrval)>] dump_stack+0x34/0x48 [<(ptrval)>] debug_check_no_locks_held+0xc8/0xd0 [<(ptrval)>] do_exit+0x6a8/0xc2c [<(ptrval)>] do_group_exit+0x68/0x114 [<(ptrval)>] __wake_up_parent+0x0/0x34 [<(ptrval)>] _syscall_return+0x0/0x4
=========================
WARNING: held lock freed!
5.14.10-rc1-00173-gcda15f9c69e0 #1 Not tainted
-------------------------
ip/182 is freeing memory 9000000002400040-90000000024006bf, with a lock still held there! 9000000002400160 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x28/0x118 2 locks held by ip/182:
#0: 90000000036a0280 (&sb->s_type->i_mutex_key#4){+.+.}-{3:3}, at: __sock_release+0x34/0xd8 #1: 9000000002400160 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x28/0x118
stack backtrace:
CPU: 0 PID: 182 Comm: ip Not tainted 5.14.10-rc1-00173-gcda15f9c69e0 #1
Stack : 0000000000000000 0000000000000000 0000000000000008 627881c1d8d1d123
90000000021453c0 0000000000000000 90000000026cbb58 ffffffff80f3b950
ffffffff81088f80 0000000000000001 90000000026cb9a8 0000000000000000
0000000000000000 0000000000000010 ffffffff8071ee00 0000000000000000
0000000000000000 ffffffff81060000 0000000000000001 ffffffff80f3b950
9000000002ab2940 000000001000a4e0 000000007fe10f68 ffffffffffffffff
0000000000000000 0000000000000000 ffffffff807a51a0 0000000000052798
ffffffff81220000 90000000026c8000 90000000026cbb50 0000000000000000
ffffffff80c7b6f0 0000000000000000 90000000026cbc88 ffffffff8121e440
00000000000000b6 0000000000000000 ffffffff8010b304 627881c1d8d1d123
...
Call Trace:
[<ffffffff8010b304>] show_stack+0x3c/0x120
[<ffffffff80c7b6f0>] dump_stack_lvl+0xa0/0xec
[<ffffffff801a8228>] debug_check_no_locks_freed+0x168/0x1a0
[<ffffffff802d679c>] kmem_cache_free.part.0+0xf4/0x2b8
[<ffffffff809eb5d0>] __sk_destruct+0x150/0x230
[<ffffffff80b22094>] inet_release+0x4c/0x88
[<ffffffff809e2744>] __sock_release+0x44/0xd8
[<ffffffff809e27ec>] sock_close+0x14/0x28
[<ffffffff802e4d84>] __fput+0xac/0x2d8
[<ffffffff80163500>] task_work_run+0x90/0xf0
[<ffffffff8010a6e8>] do_notify_resume+0x348/0x360
[<ffffffff801039e8>] work_notifysig+0x10/0x18Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on arm.
following kernel BUG reported on stable-rc linux-5.14.y while booting BeagleBoard X15 device.
metadata:
git branch: linux-5.14.y
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config: https://builds.tuxbuild.com/1z2ozt5ntwqausJUkOMJ8zBgRqi/config
Kernel crash:
--------------
[ 6.457366] kernel BUG at kernel/cpu.c:1065! [ 6.461669] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 6.466827] Modules linked in: [ 6.469909] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.14.10-rc1 #1 [ 6.476318] Hardware name: Generic DRA74X (Flattened Device Tree) [ 6.482452] PC is at cpuhp_report_idle_dead+0x74/0x78 [ 6.487518] LR is at do_idle+0x108/0x310 [ 6.491485] pc : [<c035a700>] lr : [<c03a3cc0>] psr: 20000093 [ 6.497772] sp : c2101ee0 ip : c2101f00 fp : c2101efc [ 6.503051] r10: 00000000 r9 : c2100000 r8 : 00000000 [ 6.508300] r7 : c2108fe4 r6 : eeb04414 r5 : 2ca71000 r4 : c2093414 [ 6.514862] r3 : c2101ee0 r2 : 00000000 r1 : 000000e0 r0 : 00000000 [ 6.521423] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 6.528686] Control: 10c5387d Table: 8020406a DAC: 00000051 [ 6.534454] Register r0 information: NULL pointer [ 6.539215] Register r1 information: non-paged memory [ 6.544281] Register r2 information: NULL pointer [ 6.549011] Register r3 information: non-slab/vmalloc memory [ 6.554718] Register r4 information: non-slab/vmalloc memory [ 6.560424] Register r5 information: non-paged memory [ 6.565490] Register r6 information: non-slab/vmalloc memory [ 6.571197] Register r7 information: non-slab/vmalloc memory [ 6.576904] Register r8 information: NULL pointer [ 6.581634] Register r9 information: non-slab/vmalloc memory [ 6.587310] Register r10 information: NULL pointer [ 6.592132] Register r11 information: non-slab/vmalloc memory [ 6.597930] Register r12 information: non-slab/vmalloc memory [ 6.603698] Process swapper/0 (pid: 0, stack limit = 0x(ptrval)) [ 6.609741] Stack: (0xc2101ee0 to 0xc2102000) [ 6.614135] 1ee0: 00000000 c2100000 c2108f90 c2108fe4 c2101f44 c2101f00 c03a3cc0 c035a698 [ 6.622375] 1f00: c210e0c0 00000002 c2101f00 c209f0f0 c2100000 5a76ee47 c2101f3c 000000e0 [ 6.630584] 1f20: c2101f58 00000002 c2108f40 00000000 c2100000 10c5387d c2101f54 c2101f48 [ 6.638824] 1f40: c03a4334 c03a3bc4 c2101f84 c2101f58 c1556b84 c03a4318 00000000 00000000 [ 6.647033] 1f60: c1556a88 c2101f70 c0322004 c239e068 c1fd7a80 ffffffff c2101f94 c2101f88 [ 6.655273] 1f80: c1f00af0 c15569c0 c2101ff4 c2101f98 c1f012a0 c1f00ae4 ffffffff ffffffff [ 6.663482] 1fa0: 00000000 c1f00640 00000000 00000000 00000000 00000000 00000000 c1fd7a80 [ 6.671722] 1fc0: 5a73e04d 00000000 00000000 c1f00330 00000051 10c0387d 00000000 8ffda000 [ 6.679931] 1fe0: 412fc0f2 10c5387d 00000000 c2101ff8 00000000 c1f00b78 00000000 00000000 [ 6.688140] Backtrace: [ 6.690612] [<c035a68c>] (cpuhp_report_idle_dead) from [<c03a3cc0>] (do_idle+0x108/0x310) [ 6.698852] r7:c2108fe4 r6:c2108f90 r5:c2100000 r4:00000000 [ 6.704559] [<c03a3bb8>] (do_idle) from [<c03a4334>] (cpu_startup_entry+0x28/0x2c) [ 6.712188] r10:10c5387d r9:c2100000 r8:00000000 r7:c2108f40 r6:00000002 r5:c2101f58 [ 6.720031] r4:000000e0 [ 6.722595] [<c03a430c>] (cpu_startup_entry) from [<c1556b84>] (rest_init+0x1d0/0x2fc) [ 6.730560] [<c15569b4>] (rest_init) from [<c1f00af0>] (arch_call_rest_init+0x18/0x1c) [ 6.738555] r6:ffffffff r5:c1fd7a80 r4:c239e068 [ 6.743194] [<c1f00ad8>] (arch_call_rest_init) from [<c1f012a0>] (start_kernel+0x734/0x780) [ 6.751586] [<c1f00b6c>] (start_kernel) from [<00000000>] (0x0) [ 6.757568] r10:10c5387d r9:412fc0f2 r8:8ffda000 r7:00000000 r6:10c0387d r5:00000051 [ 6.765441] r4:c1f00330 [ 6.767974] Code: e34c1035 e3a03000 eb039b62 e89da8f0 (e7f001f2) [ 6.774108] ---[ end trace 8e1c46209559ca84 ]---
ref:
https://lkft.validation.linaro.org/scheduler/job/3659621#L2841
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 107 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on arm.
following kernel BUG reported on stable-rc linux-5.14.y while booting BeagleBoard X15 device.metadata:
git branch: linux-5.14.y
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git commit:cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config: https://builds.tuxbuild.com/1z2ozt5ntwqausJUkOMJ8zBgRqi/configKernel crash:
--------------[ 6.457366] kernel BUG at kernel/cpu.c:1065! [ 6.461669] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 6.466827] Modules linked in: [ 6.469909] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.14.10-rc1 #1 [ 6.476318] Hardware name: Generic DRA74X (Flattened Device Tree) [ 6.482452] PC is at cpuhp_report_idle_dead+0x74/0x78 [ 6.487518] LR is at do_idle+0x108/0x310 [ 6.491485] pc : [<c035a700>] lr : [<c03a3cc0>] psr: 20000093 [ 6.497772] sp : c2101ee0 ip : c2101f00 fp : c2101efc [ 6.503051] r10: 00000000 r9 : c2100000 r8 : 00000000 [ 6.508300] r7 : c2108fe4 r6 : eeb04414 r5 : 2ca71000 r4 : c2093414 [ 6.514862] r3 : c2101ee0 r2 : 00000000 r1 : 000000e0 r0 : 00000000 [ 6.521423] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 6.528686] Control: 10c5387d Table: 8020406a DAC: 00000051 [ 6.534454] Register r0 information: NULL pointer [ 6.539215] Register r1 information: non-paged memory [ 6.544281] Register r2 information: NULL pointer [ 6.549011] Register r3 information: non-slab/vmalloc memory [ 6.554718] Register r4 information: non-slab/vmalloc memory [ 6.560424] Register r5 information: non-paged memory [ 6.565490] Register r6 information: non-slab/vmalloc memory [ 6.571197] Register r7 information: non-slab/vmalloc memory [ 6.576904] Register r8 information: NULL pointer [ 6.581634] Register r9 information: non-slab/vmalloc memory [ 6.587310] Register r10 information: NULL pointer [ 6.592132] Register r11 information: non-slab/vmalloc memory [ 6.597930] Register r12 information: non-slab/vmalloc memory [ 6.603698] Process swapper/0 (pid: 0, stack limit = 0x(ptrval)) [ 6.609741] Stack: (0xc2101ee0 to 0xc2102000) [ 6.614135] 1ee0: 00000000 c2100000 c2108f90 c2108fe4 c2101f44 c2101f00 c03a3cc0 c035a698 [ 6.622375] 1f00: c210e0c0 00000002 c2101f00 c209f0f0 c2100000 5a76ee47 c2101f3c 000000e0 [ 6.630584] 1f20: c2101f58 00000002 c2108f40 00000000 c2100000 10c5387d c2101f54 c2101f48 [ 6.638824] 1f40: c03a4334 c03a3bc4 c2101f84 c2101f58 c1556b84 c03a4318 00000000 00000000 [ 6.647033] 1f60: c1556a88 c2101f70 c0322004 c239e068 c1fd7a80 ffffffff c2101f94 c2101f88 [ 6.655273] 1f80: c1f00af0 c15569c0 c2101ff4 c2101f98 c1f012a0 c1f00ae4 ffffffff ffffffff [ 6.663482] 1fa0: 00000000 c1f00640 00000000 00000000 00000000 00000000 00000000 c1fd7a80 [ 6.671722] 1fc0: 5a73e04d 00000000 00000000 c1f00330 00000051 10c0387d 00000000 8ffda000 [ 6.679931] 1fe0: 412fc0f2 10c5387d 00000000 c2101ff8 00000000 c1f00b78 00000000 00000000 [ 6.688140] Backtrace: [ 6.690612] [<c035a68c>] (cpuhp_report_idle_dead) from [<c03a3cc0>] (do_idle+0x108/0x310) [ 6.698852] r7:c2108fe4 r6:c2108f90 r5:c2100000 r4:00000000 [ 6.704559] [<c03a3bb8>] (do_idle) from [<c03a4334>] (cpu_startup_entry+0x28/0x2c) [ 6.712188] r10:10c5387d r9:c2100000 r8:00000000 r7:c2108f40 r6:00000002 r5:c2101f58 [ 6.720031] r4:000000e0 [ 6.722595] [<c03a430c>] (cpu_startup_entry) from [<c1556b84>] (rest_init+0x1d0/0x2fc) [ 6.730560] [<c15569b4>] (rest_init) from [<c1f00af0>] (arch_call_rest_init+0x18/0x1c) [ 6.738555] r6:ffffffff r5:c1fd7a80 r4:c239e068 [ 6.743194] [<c1f00ad8>] (arch_call_rest_init) from [<c1f012a0>] (start_kernel+0x734/0x780) [ 6.751586] [<c1f00b6c>] (start_kernel) from [<00000000>] (0x0) [ 6.757568] r10:10c5387d r9:412fc0f2 r8:8ffda000 r7:00000000 r6:10c0387d r5:00000051 [ 6.765441] r4:c1f00330 [ 6.767974] Code: e34c1035 e3a03000 eb039b62 e89da8f0 (e7f001f2) [ 6.774108] ---[ end trace 8e1c46209559ca84 ]---
Quoted 8 lines
ref:
https://lkft.validation.linaro.org/scheduler/job/3659621#L2841Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Any chance at bisection?
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on i386 and x86.
following kernel warning reported on stable-rc linux-5.14.y while booting x86.
metadata:
git branch: linux-5.14.y
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit: cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.14/36/config
Kernel crash:
--------------
[ 22.356755] =========================
[ 22.360414] WARNING: held lock freed!
[ 22.364071] 5.14.10-rc1 #1 Not tainted
[ 22.367824] -------------------------
[ 22.371489] systemd-network/341 is freeing memory
ffff9d21cbea0000-ffff9d21cbea06bf, with a lock still held there!
[ 22.381828] ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0}, at:
sk_common_release+0x21/0x100
[ 22.384624] igb 0000:02:00.0 eno2: renamed from eth1
[ 22.390260] 2 locks held by systemd-network/341:
[ 22.390261] #0: ffff9d21c406eb10
(&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release+0x32/0xc0
[ 22.390267] #1: ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0},
at: sk_common_release+0x21/0x100
[ 22.390272]
[ 22.390272] stack backtrace:
[ 22.390273] CPU: 2 PID: 341 Comm: systemd-network Not tainted 5.14.10-rc1 #1
[ 22.390275] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 22.390276] Call Trace:
[ 22.390278] dump_stack_lvl+0x49/0x5e
[ 22.390281] dump_stack+0x10/0x12
[ 22.390283] debug_check_no_locks_freed+0x111/0x120
[ 22.390286] slab_free_freelist_hook+0x119/0x1d0
[ 22.390289] kmem_cache_free+0x102/0x540
[ 22.390291] ? __sk_destruct+0x145/0x210
[ 22.390294] __sk_destruct+0x145/0x210
[ 22.390296] sk_destruct+0x48/0x50
[ 22.409489] ata_id (348) used greatest stack depth: 11952 bytes left
[ 22.418194] __sk_free+0x2f/0xc0
[ 22.418198] sk_free+0x26/0x40
[ 22.418200] sk_common_release+0xa9/0x100
[ 22.487567] udp_lib_close+0x9/0x10
[ 22.491057] inet_release+0x44/0x80
[ 22.494542] __sock_release+0x42/0xc0
[ 22.498209] sock_close+0x18/0x20
[ 22.501525] __fput+0xb5/0x260
[ 22.504578] ____fput+0xe/0x10
[ 22.507636] task_work_run+0x6f/0xc0
[ 22.511216] exit_to_user_mode_prepare+0x1f6/0x200
[ 22.515999] syscall_exit_to_user_mode+0x1d/0x50
[ 22.520610] do_syscall_64+0x67/0x80
[ 22.524190] ? irqentry_exit+0x75/0x80
[ 22.527940] ? exc_page_fault+0x6c/0x200
[ 22.531859] ? asm_exc_page_fault+0x8/0x30
[ 22.535950] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 22.541002] RIP: 0033:0x7f52fe67e641
[ 22.544580] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 8b 05 aa cd 20 00 85 c0 75 16 b8 03 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 3f c3 66 0f 1f 44 00 00 53 89 fb 48 83
ec 10
[ 22.563318] RSP: 002b:00007ffe31761878 EFLAGS: 00000246 ORIG_RAX:
0000000000000003
[ 22.570884] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00007f52fe67e641
[ 22.578007] RDX: 00000000000073b0 RSI: 0000000000000000 RDI: 0000000000000010
[ 22.585130] RBP: 00007f52feed8338 R08: 000055893cf103c3 R09: 0000000000000078
[ 22.592253] R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
[ 22.599379] R13: 00007ffe317618c0 R14: 0000000000000000 R15: 00007ffe31762a60ref:
https://lkft.validation.linaro.org/scheduler/job/3658919#L1477
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 95 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.14.10 release. There are 172 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 06 Oct 2021 12:50:17 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.14.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on i386 and x86.
following kernel warning reported on stable-rc linux-5.14.y while booting x86.metadata:
git branch: linux-5.14.y
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit:cda15f9c69e08480d4308d0e5c62bd44324a9ff0
git describe: v5.14.9-173-gcda15f9c69e0
make_kernelversion: 5.14.10-rc1
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.14/36/configKernel crash:
--------------[ 22.356755] ========================= [ 22.360414] WARNING: held lock freed! [ 22.364071] 5.14.10-rc1 #1 Not tainted [ 22.367824] ------------------------- [ 22.371489] systemd-network/341 is freeing memory ffff9d21cbea0000-ffff9d21cbea06bf, with a lock still held there! [ 22.381828] ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x21/0x100 [ 22.384624] igb 0000:02:00.0 eno2: renamed from eth1 [ 22.390260] 2 locks held by systemd-network/341: [ 22.390261] #0: ffff9d21c406eb10 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release+0x32/0xc0 [ 22.390267] #1: ffff9d21cbea0120 (sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x21/0x100 [ 22.390272] [ 22.390272] stack backtrace: [ 22.390273] CPU: 2 PID: 341 Comm: systemd-network Not tainted 5.14.10-rc1 #1 [ 22.390275] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.0b 07/27/2017 [ 22.390276] Call Trace: [ 22.390278] dump_stack_lvl+0x49/0x5e [ 22.390281] dump_stack+0x10/0x12 [ 22.390283] debug_check_no_locks_freed+0x111/0x120 [ 22.390286] slab_free_freelist_hook+0x119/0x1d0 [ 22.390289] kmem_cache_free+0x102/0x540 [ 22.390291] ? __sk_destruct+0x145/0x210 [ 22.390294] __sk_destruct+0x145/0x210 [ 22.390296] sk_destruct+0x48/0x50 [ 22.409489] ata_id (348) used greatest stack depth: 11952 bytes left [ 22.418194] __sk_free+0x2f/0xc0 [ 22.418198] sk_free+0x26/0x40 [ 22.418200] sk_common_release+0xa9/0x100 [ 22.487567] udp_lib_close+0x9/0x10 [ 22.491057] inet_release+0x44/0x80 [ 22.494542] __sock_release+0x42/0xc0 [ 22.498209] sock_close+0x18/0x20 [ 22.501525] __fput+0xb5/0x260 [ 22.504578] ____fput+0xe/0x10 [ 22.507636] task_work_run+0x6f/0xc0 [ 22.511216] exit_to_user_mode_prepare+0x1f6/0x200 [ 22.515999] syscall_exit_to_user_mode+0x1d/0x50 [ 22.520610] do_syscall_64+0x67/0x80 [ 22.524190] ? irqentry_exit+0x75/0x80 [ 22.527940] ? exc_page_fault+0x6c/0x200 [ 22.531859] ? asm_exc_page_fault+0x8/0x30 [ 22.535950] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 22.541002] RIP: 0033:0x7f52fe67e641 [ 22.544580] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 8b 05 aa cd 20 00 85 c0 75 16 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3f c3 66 0f 1f 44 00 00 53 89 fb 48 83 ec 10 [ 22.563318] RSP: 002b:00007ffe31761878 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 22.570884] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00007f52fe67e641 [ 22.578007] RDX: 00000000000073b0 RSI: 0000000000000000 RDI: 0000000000000010 [ 22.585130] RBP: 00007f52feed8338 R08: 000055893cf103c3 R09: 0000000000000078 [ 22.592253] R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000 [ 22.599379] R13: 00007ffe317618c0 R14: 0000000000000000 R15: 00007ffe31762a60
Quoted 8 lines
ref:
https://lkft.validation.linaro.org/scheduler/job/3658919#L1477Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Any chance at bisection?