4.19.309-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.19.309-rc1 review
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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 Mar 2024 21:15:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.309-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.309-rc1
Arturas Moskvinas <[email protected]>
gpio: 74x164: Enable output pins after registers are reset
Baokun Li <[email protected]>
cachefiles: fix memory leak in cachefiles_add_cache()
Ivan Semenov <[email protected]>
mmc: core: Fix eMMC initialization with 1-bit bus connection
David Sterba <[email protected]>
btrfs: dev-replace: properly validate device names
Johannes Berg <[email protected]>
wifi: nl80211: reject iftype change with mesh ID change
Alexander Ofitserov <[email protected]>
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
Takashi Iwai <[email protected]>
ALSA: Drop leftover snd-rtctimer stuff from Makefile
Hans de Goede <[email protected]>
power: supply: bq27xxx-i2c: Do not free non existing IRQ
Arnd Bergmann <[email protected]>
efi/capsule-loader: fix incorrect allocation size
Kai-Heng Feng <[email protected]>
Bluetooth: Enforce validation on max value of connection interval
Luiz Augusto von Dentz <[email protected]>
Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
Ying Hsu <[email protected]>
Bluetooth: Avoid potential use-after-free in hci_error_reset
Javier Carrasco <[email protected]>
net: usb: dm9601: fix wrong return value in dm9601_mdio_read
Oleksij Rempel <[email protected]>
lan78xx: enable auto speed configuration for LAN7850 if no EEPROM is detected
Yunjian Wang <[email protected]>
tun: Fix xdp_rxq_info's queue_index when detaching
Ryosuke Yasuoka <[email protected]>
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
-------------
Diffstat:
Makefile | 4 ++-- drivers/firmware/efi/capsule-loader.c | 2 +- drivers/gpio/gpio-74x164.c | 4 ++-- drivers/mmc/core/mmc.c | 2 ++ drivers/net/gtp.c | 12 ++++++------ drivers/net/tun.c | 1 + drivers/net/usb/dm9601.c | 2 +- drivers/net/usb/lan78xx.c | 3 ++- drivers/power/supply/bq27xxx_battery_i2c.c | 4 +++- fs/btrfs/dev-replace.c | 24 ++++++++++++++++++++---- fs/cachefiles/bind.c | 3 +++ net/bluetooth/hci_core.c | 7 ++++--- net/bluetooth/hci_event.c | 9 ++++++++- net/bluetooth/l2cap_core.c | 8 +++++++- net/netlink/af_netlink.c | 2 +- net/wireless/nl80211.c | 2 ++ sound/core/Makefile | 1 - 17 files changed, 65 insertions(+), 25 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/16 netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryosuke Yasuoka <[email protected]>
[ Upstream commit 661779e1fcafe1b74b3f3fe8e980c1e207fea1fd ]
syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new skb and puts the skb->data passed as a 1st arg of netlink_to_full_skb() onto new skb. The data size is specified as len and passed to skb_put_data(). This len is based on skb->end that is not data offset but buffer offset. The skb->end contains data and tailroom. Since the tailroom is not initialized when the new skb created, KMSAN detects uninitialized memory area when copying the data.
This patch resolved this issue by correct the len from skb->end to skb->len, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was stored to memory at:
skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages_flush mm/mmu_gather.c:98 [inline] tlb_flush_mmu_free mm/mmu_gather.c:293 [inline] tlb_flush_mmu+0x6f5/0x980 mm/mmu_gather.c:300 tlb_finish_mmu+0x101/0x260 mm/mmu_gather.c:392 exit_mmap+0x49e/0xd30 mm/mmap.c:3321 __mmput+0x13f/0x530 kernel/fork.c:1349 mmput+0x8a/0xa0 kernel/fork.c:1371 exit_mm+0x1b8/0x360 kernel/exit.c:567 do_exit+0xd57/0x4080 kernel/exit.c:858 do_group_exit+0x2fd/0x390 kernel/exit.c:1021 __do_sys_exit_group kernel/exit.c:1032 [inline] __se_sys_exit_group kernel/exit.c:1030 [inline] __x64_sys_exit_group+0x3c/0x50 kernel/exit.c:1030 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Bytes 3852-3903 of 3904 are uninitialized Memory access of size 3904 starts at ffff88812ea1e000 Data copied to user address 0000000020003280
CPU: 1 PID: 5043 Comm: syz-executor297 Not tainted 6.7.0-rc5-syzkaller-00047-g5bd7ef53ffe5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
--- net/netlink/af_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netlink/af_netlink.c +1 -1
@@ -160,7 +160,7 @@ static inline u32 netlink_group_mask(u32 group)static struct sk_buff *netlink_to_full_skb (const struct sk_buff *skb,gfp_t gfp_mask) { -unsigned int len =skb_end_offset (skb); +unsigned int len = skb->len;struct sk_buff *new; new =alloc_skb (len, gfp_mask);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 2/16 tun: Fix xdp_rxq_infos queue_index when detaching
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yunjian Wang <[email protected]>
[ Upstream commit 2a770cdc4382b457ca3d43d03f0f0064f905a0d0 ]
When a queue(tfile) is detached, we only update tfile's queue_index, but do not update xdp_rxq_info's queue_index. This patch fixes it.
--- drivers/net/tun.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/tun.c +1 -0
@@ -729,6 +729,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean) tun->tfiles[tun->numqueues - 1]); ntfile =rtnl_dereference (tun->tfiles[index]); ntfile->queue_index = index; + ntfile->xdp_rxq.queue_index = index;rcu_assign_pointer (tun->tfiles[tun->numqueues -1 ],NULL );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 3/16 lan78xx: enable auto speed configuration for LAN7850 if no EEPROM is detected
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleksij Rempel <[email protected]>
[ Upstream commit 0e67899abfbfdea0c3c0ed3fd263ffc601c5c157 ]
Same as LAN7800, LAN7850 can be used without EEPROM. If EEPROM is not present or not flashed, LAN7850 will fail to sync the speed detected by the PHY with the MAC. In case link speed is 100Mbit, it will accidentally work, otherwise no data can be transferred.
Better way would be to implement link_up callback, or set auto speed configuration unconditionally. But this changes would be more intrusive. So, for now, set it only if no EEPROM is found.
--- drivers/net/usb/lan78xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/usb/lan78xx.c +2 -1
@@ -2581,7 +2581,8 @@ static int lan78xx_reset(struct lan78xx_net *dev)if (dev->chipid ==ID_REV_CHIP_ID_7801_ ) buf &= ~MAC_CR_GMII_EN_ ; -if (dev->chipid ==ID_REV_CHIP_ID_7800_ ) { +if (dev->chipid ==ID_REV_CHIP_ID_7800_ || + dev->chipid ==ID_REV_CHIP_ID_7850_ ) { ret =lan78xx_read_raw_eeprom (dev,0 ,1 , &sig);if (!ret && sig !=EEPROM_INDICATOR ) {/* Implies there is no external eeprom. Set mac speed */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 4/16 net: usb: dm9601: fix wrong return value in dm9601_mdio_read
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit c68b2c9eba38ec3f60f4894b189090febf4d8d22 ]
The MII code does not check the return value of mdio_read (among others), and therefore no error code should be sent. A previous fix to the use of an uninitialized variable propagates negative error codes, that might lead to wrong operations by the MII library.
An example of such issues is the use of mii_nway_restart by the dm9601 driver. The mii_nway_restart function does not check the value returned by mdio_read, which in this case might be a negative number which could contain the exact bit the function checks (BMCR_ANENABLE = 0x1000).
Return zero in case of error, as it is common practice in users of mdio_read to avoid wrong uses of the return value.
--- drivers/net/usb/dm9601.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/usb/dm9601.c +1 -1
@@ -231,7 +231,7 @@ static int dm9601_mdio_read(struct net_device *netdev, int phy_id, int loc) err =dm_read_shared_word (dev,1 , loc, &res);if (err <0 ) {netdev_err (dev->net,"MDIO read error: %d\n" , err); -return err; +return 0 ; } netdev_dbg(dev->net,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 5/16 Bluetooth: Avoid potential use-after-free in hci_error_reset
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ying Hsu <[email protected]>
[ Upstream commit 2449007d3f73b2842c9734f45f0aadb522daf592 ]
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+0x1d8/0x33f
worker_thread+0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/0x54
? kthread_blkcg+0x31/0x31
ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash.
--- net/bluetooth/hci_core.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/bluetooth/hci_core.c +4 -3
@@ -2217,6 +2217,7 @@ static void hci_error_reset(struct work_struct *work) { struct hci_dev *hdev = container_of(work, struct hci_dev, error_reset); +hci_dev_hold (hdev);BT_DBG ("%s" , hdev->name);if (hdev->hw_error)
@@ -2224,10 +2225,10 @@ static void hci_error_reset(struct work_struct *work)else bt_dev_err (hdev,"hardware error 0x%2.2x" , hdev->hw_error_code); -if (hci_dev_do_close (hdev)) -return ; +if (!hci_dev_do_close (hdev)) +hci_dev_do_open (hdev); -hci_dev_do_open (hdev); +hci_dev_put (hdev); }void hci_uuids_clear (struct hci_dev *hdev)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 6/16 Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865 ]
If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.
--- net/bluetooth/hci_event.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/bluetooth/hci_event.c +4 -1
@@ -4337,9 +4337,12 @@ static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb)hci_dev_lock (hdev); conn =hci_conn_hash_lookup_ba (hdev,ACL_LINK , &ev->bdaddr); -if (!conn || !hci_conn_ssp_enabled (conn)) +if (!conn || !hci_dev_test_flag (hdev,HCI_SSP_ENABLED )) goto unlock; +/* Assume remote supports SSP since it has triggered this event */ +set_bit (HCI_CONN_SSP_ENABLED , &conn->flags); +hci_conn_hold (conn);if (!hci_dev_test_flag (hdev,HCI_MGMT ))
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 7/16 Bluetooth: Enforce validation on max value of connection interval
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
[ Upstream commit e4b019515f950b4e6e5b74b2e1bb03a90cb33039 ]
Right now Linux BT stack cannot pass test case "GAP/CONN/CPUP/BV-05-C 'Connection Parameter Update Procedure Invalid Parameters Central Responder'" in Bluetooth Test Suite revision GAP.TS.p44. [0]
That was revoled by commit c49a8682fc5d ("Bluetooth: validate BLE connection interval updates"), but later got reverted due to devices like keyboards and mice may require low connection interval.
So only validate the max value connection interval to pass the Test Suite, and let devices to request low connection interval if needed.
[0] https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=229869
--- net/bluetooth/hci_event.c | 4 ++++ net/bluetooth/l2cap_core.c | 8 +++++++- 2 files changed, 11 insertions(+), 1 deletion(-)
net/bluetooth/hci_event.c +4 -0
@@ -5641,6 +5641,10 @@ static void hci_le_remote_conn_param_req_evt(struct hci_dev *hdev,return send_conn_param_neg_reply (hdev, handle,HCI_ERROR_UNKNOWN_CONN_ID ); +if (max > hcon->le_conn_max_interval) +return send_conn_param_neg_reply (hdev, handle, +HCI_ERROR_INVALID_LL_PARAMS ); +if (hci_check_conn_params (min, max, latency, timeout))return send_conn_param_neg_reply (hdev, handle,HCI_ERROR_INVALID_LL_PARAMS );
net/bluetooth/l2cap_core.c +7 -1
@@ -5313,7 +5313,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,memset (&rsp,0 ,sizeof (rsp)); - err =hci_check_conn_params (min, max, latency, to_multiplier); +if (max > hcon->le_conn_max_interval) { +BT_DBG ("requested connection interval exceeds current bounds." ); + err = -EINVAL ; + }else { + err =hci_check_conn_params (min, max, latency, to_multiplier); + } +if (err) rsp.result =cpu_to_le16 (L2CAP_CONN_PARAM_REJECTED );else
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 8/16 efi/capsule-loader: fix incorrect allocation size
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ]
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
| ^
Use the correct type instead here.
--- drivers/firmware/efi/capsule-loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/capsule-loader.c +1 -1
@@ -293,7 +293,7 @@ static int efi_capsule_open(struct inode *inode, struct file *file)return -ENOMEM ; } - cap_info->phys =kzalloc (sizeof (void *),GFP_KERNEL ); + cap_info->phys =kzalloc (sizeof (phys_addr_t),GFP_KERNEL );if (!cap_info->phys) {kfree (cap_info->pages);kfree (cap_info);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 9/16 power: supply: bq27xxx-i2c: Do not free non existing IRQ
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 2df70149e73e79783bcbc7db4fa51ecef0e2022c ]
The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq().
But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.
--- drivers/power/supply/bq27xxx_battery_i2c.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/power/supply/bq27xxx_battery_i2c.c +3 -1
@@ -217,7 +217,9 @@ static int bq27xxx_battery_i2c_remove(struct i2c_client *client) {struct bq27xxx_device_info *di =i2c_get_clientdata (client); -free_irq (client->irq, di); +if (client->irq) +free_irq (client->irq, di); +bq27xxx_battery_teardown (di);mutex_lock (&battery_mutex);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 10/16 ALSA: Drop leftover snd-rtctimer stuff from Makefile
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit 4df49712eb54141be00a9312547436d55677f092 ]
We forgot to remove the line for snd-rtctimer from Makefile while dropping the functionality. Get rid of the stale line.
--- sound/core/Makefile | 1 - 1 file changed, 1 deletion(-)
sound/core/Makefile +0 -1
@@ -32,7 +32,6 @@ snd-pcm-dmaengine-objs := pcm_dmaengine.o snd-rawmidi-objs := rawmidi.o snd-timer-objs := timer.o snd-hrtimer-objs := hrtimer.o -snd-rtctimer-objs := rtctimer.o snd-hwdep-objs := hwdep.o snd-seq-device-objs := seq_device.o
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 11/16 gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Ofitserov <[email protected]>
commit 616d82c3cfa2a2146dd7e3ae47bda7e877ee549e upstream.
The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map_type+0x2c7/0x860 [ 1010.716343] ? lockdep_hardirqs_on_prepare+0x430/0x430 [ 1010.716350] ? debug_mutex_init+0x33/0x70 [ 1010.716360] ? percpu_counter_add_batch+0x8b/0x140 [ 1010.716367] ? lock_acquire+0x1fe/0x560 [ 1010.716373] ? find_held_lock+0x2c/0x110 [ 1010.716384] ? __fd_install+0x1b6/0x6f0 [ 1010.716389] ? lock_downgrade+0x810/0x810 [ 1010.716396] ? __fget_light+0x222/0x290 [ 1010.716403] __sys_sendmsg+0xea/0x1b0 [ 1010.716409] ? __sys_sendmsg_sock+0x40/0x40 [ 1010.716419] ? lockdep_hardirqs_on_prepare+0x2b3/0x430 [ 1010.716425] ? syscall_enter_from_user_mode+0x1d/0x60 [ 1010.716432] do_syscall_64+0x30/0x40 [ 1010.716438] entry_SYSCALL_64_after_hwframe+0x62/0xc7 [ 1010.716444] RIP: 0033:0x7fd1508cbd49 [ 1010.716452] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 [ 1010.716456] RSP: 002b:00007fff18872348 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 1010.716463] RAX: ffffffffffffffda RBX: 000055f72bf0eac0 RCX: 00007fd1508cbd49 [ 1010.716468] RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000006 [ 1010.716473] RBP: 00007fff18872360 R08: 00007fff18872360 R09: 00007fff18872360 [ 1010.716478] R10: 00007fff18872360 R11: 0000000000000202 R12: 000055f72bf0e1b0 [ 1010.716482] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1010.716491] Modules linked in: gtp(+) udp_tunnel ib_core uinput af_packet rfkill qrtr joydev hid_generic usbhid hid kvm_intel iTCO_wdt intel_pmc_bxt iTCO_vendor_support kvm snd_hda_codec_generic ledtrig_audio irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel nls_utf8 snd_intel_dspcfg nls_cp866 psmouse aesni_intel vfat crypto_simd fat cryptd glue_helper snd_hda_codec pcspkr snd_hda_core i2c_i801 snd_hwdep i2c_smbus xhci_pci snd_pcm lpc_ich xhci_pci_renesas xhci_hcd qemu_fw_cfg tiny_power_button button sch_fq_codel vboxvideo drm_vram_helper drm_ttm_helper ttm vboxsf vboxguest snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore msr fuse efi_pstore dm_mod ip_tables x_tables autofs4 virtio_gpu virtio_dma_buf drm_kms_helper cec rc_core drm virtio_rng virtio_scsi rng_core virtio_balloon virtio_blk virtio_net virtio_console net_failover failover ahci libahci libata evdev scsi_mod input_leds serio_raw virtio_pci intel_agp [ 1010.716674] virtio_ring intel_gtt virtio [last unloaded: gtp] [ 1010.716693] ---[ end trace 04990a4ce61e174b ]---
--- drivers/net/gtp.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/gtp.c +6 -6
@@ -1381,26 +1381,26 @@ static int __init gtp_init(void)get_random_bytes (>p_h_initval,sizeof (gtp_h_initval)); - err =rtnl_link_register (>p_link_ops); + err =register_pernet_subsys (>p_net_ops);if (err <0 ) goto error_out; - err =register_pernet_subsys (>p_net_ops); + err =rtnl_link_register (>p_link_ops);if (err <0 ) - goto unreg_rtnl_link; + goto unreg_pernet_subsys; err =genl_register_family (>p_genl_family);if (err <0 ) - goto unreg_pernet_subsys; + goto unreg_rtnl_link;pr_info ("GTP module loaded (pdp ctx size %zd bytes)\n" ,sizeof (struct pdp_ctx ));return 0 ; -unreg_pernet_subsys: -unregister_pernet_subsys (>p_net_ops); unreg_rtnl_link:rtnl_link_unregister (>p_link_ops); +unreg_pernet_subsys: +unregister_pernet_subsys (>p_net_ops); error_out:pr_err ("error loading GTP module loaded\n" );return err;
Greg Kroah-Hartman
maintainerPATCH 12/16 wifi: nl80211: reject iftype change with mesh ID change
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit f78c1375339a291cba492a70eaf12ec501d28a8e upstream.
It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching.
We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.
--- net/wireless/nl80211.c | 2 ++ 1 file changed, 2 insertions(+)
net/wireless/nl80211.c +2 -0
@@ -3174,6 +3174,8 @@ static int nl80211_set_interface(structif (ntype !=NL80211_IFTYPE_MESH_POINT )return -EINVAL ; +if (otype !=NL80211_IFTYPE_MESH_POINT ) +return -EINVAL ;if (netif_running (dev))return -EBUSY ;
Greg Kroah-Hartman
maintainerPATCH 13/16 btrfs: dev-replace: properly validate device names
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <[email protected]>
commit 9845664b9ee47ce7ee7ea93caf47d39a9d4552c4 upstream.
There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
--- fs/btrfs/dev-replace.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
fs/btrfs/dev-replace.c +20 -4
@@ -535,6 +535,23 @@ leave:return ret; } +static int btrfs_check_replace_dev_names (struct btrfs_ioctl_dev_replace_args *args) +{ +if (args->start.srcdevid ==0 ) { +if (memchr (args->start.srcdev_name,0 , +sizeof (args->start.srcdev_name)) ==NULL ) +return -ENAMETOOLONG ; + }else { + args->start.srcdev_name[0 ] =0 ; + } + +if (memchr (args->start.tgtdev_name,0 , +sizeof (args->start.tgtdev_name)) ==NULL ) +return -ENAMETOOLONG ; + +return 0 ; +} +int btrfs_dev_replace_by_ioctl (struct btrfs_fs_info *fs_info,struct btrfs_ioctl_dev_replace_args *args) {
@@ -547,10 +564,9 @@ int btrfs_dev_replace_by_ioctl(struct btdefault :return -EINVAL ; } - -if ((args->start.srcdevid ==0 && args->start.srcdev_name[0 ] =='\0' ) || - args->start.tgtdev_name[0 ] =='\0' ) -return -EINVAL ; + ret =btrfs_check_replace_dev_names (args); +if (ret <0 ) +return ret; ret = btrfs_dev_replace_start(fs_info, args->start.tgtdev_name, args->start.srcdevid,
Greg Kroah-Hartman
maintainerPATCH 14/16 mmc: core: Fix eMMC initialization with 1-bit bus connection
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Semenov <[email protected]>
commit ff3206d2186d84e4f77e1378ba1d225633f17b9b upstream.
Initializing an eMMC that's connected via a 1-bit bus is current failing, if the HW (DT) informs that 4-bit bus is supported. In fact this is a regression, as we were earlier capable of falling back to 1-bit mode, when switching to 4/8-bit bus failed. Therefore, let's restore the behaviour.
Log for Samsung eMMC 5.1 chip connected via 1bit bus (only D0 pin) Before patch:
[134509.044225] mmc0: switch to bus width 4 failed [134509.044509] mmc0: new high speed MMC card at address 0001 [134509.054594] mmcblk0: mmc0:0001 BGUF4R 29.1 GiB [134509.281602] mmc0: switch to bus width 4 failed [134509.282638] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.282657] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.284598] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.284602] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.284609] ldm_validate_partition_table(): Disk read failed. [134509.286495] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.286500] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.288303] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.288308] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.289540] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.289544] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.289553] mmcblk0: unable to read partition table [134509.289728] mmcblk0boot0: mmc0:0001 BGUF4R 31.9 MiB [134509.290283] mmcblk0boot1: mmc0:0001 BGUF4R 31.9 MiB [134509.294577] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 [134509.295835] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.295841] Buffer I/O error on dev mmcblk0, logical block 0, async page read
After patch:
[134551.089613] mmc0: switch to bus width 4 failed [134551.090377] mmc0: new high speed MMC card at address 0001 [134551.102271] mmcblk0: mmc0:0001 BGUF4R 29.1 GiB [134551.113365] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 [134551.114262] mmcblk0boot0: mmc0:0001 BGUF4R 31.9 MiB [134551.114925] mmcblk0boot1: mmc0:0001 BGUF4R 31.9 MiB
--- drivers/mmc/core/mmc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/mmc/core/mmc.c +2 -0
@@ -994,10 +994,12 @@ static int mmc_select_bus_width(struct mstatic unsigned ext_csd_bits[] = {EXT_CSD_BUS_WIDTH_8 ,EXT_CSD_BUS_WIDTH_4 , +EXT_CSD_BUS_WIDTH_1 , };static unsigned bus_widths[] = {MMC_BUS_WIDTH_8 ,MMC_BUS_WIDTH_4 , +MMC_BUS_WIDTH_1 , };struct mmc_host *host = card->host;unsigned idx, bus_width =0 ;
Greg Kroah-Hartman
maintainerPATCH 15/16 cachefiles: fix memory leak in cachefiles_add_cache()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream.
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks.
--- fs/cachefiles/bind.c | 3 +++ 1 file changed, 3 insertions(+)
fs/cachefiles/bind.c +3 -0
@@ -249,6 +249,8 @@ error_open_root:kmem_cache_free (cachefiles_object_jar, fsdef); error_root_object:cachefiles_end_secure (cache, saved_cred); +put_cred (cache->cache_cred); + cache->cache_cred =NULL ;pr_err ("Failed to register: %d\n" , ret);return ret; }
@@ -269,6 +271,7 @@ void cachefiles_daemon_unbind(struct cacdput (cache->graveyard);mntput (cache->mnt); +put_cred (cache->cache_cred);kfree (cache->rootdirname);kfree (cache->secctx);
Greg Kroah-Hartman
maintainerPATCH 16/16 gpio: 74x164: Enable output pins after registers are reset
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arturas Moskvinas <[email protected]>
[ Upstream commit 530b1dbd97846b110ea8a94c7cc903eca21786e5 ]
Chip outputs are enabled[1] before actual reset is performed[2] which might cause pin output value to flip flop if previous pin value was set to 1. Fix that behavior by making sure chip is fully reset before all outputs are enabled.
Flip-flop can be noticed when module is removed and inserted again and one of the pins was changed to 1 before removal. 100 microsecond flipping is noticeable on oscilloscope (100khz SPI bus).
For a properly reset chip - output is enabled around 100 microseconds (on 100khz SPI bus) later during probing process hence should be irrelevant behavioral change.
--- drivers/gpio/gpio-74x164.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpio/gpio-74x164.c +2 -2
@@ -132,8 +132,6 @@ static int gen_74x164_probe(struct spi_device *spi)if (IS_ERR (chip->gpiod_oe))return PTR_ERR (chip->gpiod_oe); -gpiod_set_value_cansleep (chip->gpiod_oe,1 ); -spi_set_drvdata (spi, chip); chip->gpio_chip.label = spi->modalias;
@@ -158,6 +156,8 @@ static int gen_74x164_probe(struct spi_device *spi) goto exit_destroy; } +gpiod_set_value_cansleep (chip->gpiod_oe,1 ); + ret =gpiochip_add_data (&chip->gpio_chip, chip);if (!ret)return 0 ;
Signature · 1 line
2.43.0
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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 Mar 2024 21:15:26 +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/v4.x/stable-review/patch-4.19.309-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.19:
10 builds: 10 pass, 0 fail
20 boots: 20 pass, 0 fail
37 tests: 37 pass, 0 failLinux version: 4.19.309-rc1-gc854e1c772c4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Jon
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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. But note we don't test risc-v on this version.
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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 Mar 2024 21:15:26 +0000. Anything received after that time might be too late.
Built and boot tested on x86_64 and aarch64.
Thanks,
Harshit
Quoted 10 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.309-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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 Mar 2024 21:15:26 +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/v4.x/stable-review/patch-4.19.309-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.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 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.309 release. There are 16 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 Mar 2024 21:15:26 +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/v4.x/stable-review/patch-4.19.309-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 4.19.309-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.19.y
* git commit: c854e1c772c4f07a8856c0867118ce064c11fead
* git describe: v4.19.307-70-gc854e1c772c4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.307-70-gc854e1c772c4
## Test Regressions (compared to v4.19.307)
## Metric Regressions (compared to v4.19.307)
## Test Fixes (compared to v4.19.307)
## Metric Fixes (compared to v4.19.307)
## Test result summary
total: 51688, pass: 45911, fail: 287, skip: 5449, xfail: 41
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 106 total, 99 passed, 7 failed
* arm64: 31 total, 25 passed, 6 failed
* i386: 18 total, 15 passed, 3 failed
* mips: 23 total, 22 passed, 1 failed
* parisc: 4 total, 0 passed, 4 failed
* powerpc: 27 total, 26 passed, 1 failed
* s390: 8 total, 8 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 27 total, 21 passed, 6 failed
## Test suites summary
* boot
* kselftest-drivers-dma-buf
* kselftest-net
* kselftest-net-mptcp
* kunit
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org