4.9.327-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.9.327-rc1 review
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +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.9.327-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.327-rc1
Kuniyuki Iwashima <[email protected]>
kprobes: don't call disarm_kprobe() for disabled kprobes
Jann Horn <[email protected]>
mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse
Geert Uytterhoeven <[email protected]>
netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y
Juergen Gross <[email protected]>
s390/hypfs: avoid error message under KVM
Hsin-Yi Wang <[email protected]>
arm64: map FDT as RW for early_init_dt_scan()
Yang Jihong <[email protected]>
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
Letu Ren <[email protected]>
fbdev: fb_pm2fb: Avoid potential divide by zero error
Karthik Alapati <[email protected]>
HID: hidraw: fix memory leak in hidraw_release()
Dongliang Mu <[email protected]>
media: pvrusb2: fix memory leak in pvr_probe
Luiz Augusto von Dentz <[email protected]>
Bluetooth: L2CAP: Fix build errors in some archs
Jing Leng <[email protected]>
kbuild: Fix include path in scripts/Makefile.modpost
Pawan Gupta <[email protected]>
x86/bugs: Add "unknown" reporting for MMIO Stale Data
Gayatri Kammela <[email protected]>
x86/cpu: Add Tiger Lake to Intel family
Gerald Schaefer <[email protected]>
s390/mm: do not trigger write fault when vma does not allow VM_WRITE
Jann Horn <[email protected]>
mm: Force TLB flush for PFNMAP mappings before unlink_file_vma()
David Hildenbrand <[email protected]>
mm/hugetlb: fix hugetlb not supporting softdirty tracking
Quanyang Wang <[email protected]>
asm-generic: sections: refactor memory_intersects
Siddh Raman Pant <[email protected]>
loop: Check for overflow while configuring loop
Goldwyn Rodrigues <[email protected]>
btrfs: check if root is readonly while setting security xattr
Jacob Keller <[email protected]>
ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter
Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_somaxconn.
Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_net_busy_read.
Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_net_busy_poll.
Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_tstamp_allow_data.
Kuniyuki Iwashima <[email protected]>
ratelimit: Fix data-races in ___ratelimit().
Pablo Neira Ayuso <[email protected]>
netfilter: nft_payload: report ERANGE for too long offset and length
Jonathan Toppins <[email protected]>
bonding: 802.3ad: fix no transmission of LACPDUs
Bernard Pidoux <[email protected]>
rose: check NULL rose_loopback_neigh->loopback
Herbert Xu <[email protected]>
af_key: Do not call xfrm_probe_algs in parallel
Xin Xiong <[email protected]>
xfrm: fix refcount leak in __xfrm_policy_check()
Helge Deller <[email protected]>
parisc: Fix exception handler for fldw and fstw instructions
-------------
Diffstat:
.../hw-vuln/processor_mmio_stale_data.rst | 14 +++++ Makefile | 4 +- arch/arm64/include/asm/mmu.h | 2 +- arch/arm64/kernel/kaslr.c | 5 +- arch/arm64/kernel/setup.c | 9 +++- arch/arm64/mm/mmu.c | 15 +----- arch/parisc/kernel/unaligned.c | 2 +- arch/s390/hypfs/hypfs_diag.c | 2 +- arch/s390/hypfs/inode.c | 2 +- arch/s390/mm/fault.c | 4 +- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/intel-family.h | 3 ++ arch/x86/kernel/cpu/bugs.c | 14 ++++- arch/x86/kernel/cpu/common.c | 34 +++++++++---- drivers/block/loop.c | 5 ++ drivers/hid/hidraw.c | 3 ++ drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 + drivers/net/bonding/bond_3ad.c | 38 ++++++-------- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 59 +++++++++++++++++----- drivers/video/fbdev/pm2fb.c | 5 ++ fs/btrfs/xattr.c | 3 ++ include/asm-generic/sections.h | 7 ++- include/linux/rmap.h | 7 ++- include/net/busy_poll.h | 2 +- kernel/kprobes.c | 10 ++-- kernel/trace/ftrace.c | 10 ++++ lib/ratelimit.c | 12 +++-- mm/mmap.c | 20 +++++++- mm/rmap.c | 31 +++++++----- net/bluetooth/l2cap_core.c | 10 ++-- net/core/skbuff.c | 2 +- net/core/sock.c | 2 +- net/key/af_key.c | 3 ++ net/netfilter/Kconfig | 1 - net/netfilter/nft_payload.c | 10 +++- net/rose/rose_loopback.c | 3 +- net/socket.c | 2 +- net/xfrm/xfrm_policy.c | 1 + scripts/Makefile.modpost | 3 +- 39 files changed, 245 insertions(+), 116 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/31 parisc: Fix exception handler for fldw and fstw instructions
From: Helge Deller <[email protected]>
commit 7ae1f5508d9a33fd58ed3059bd2d569961e3b8bd upstream.
The exception handler is broken for unaligned memory acceses with fldw and fstw instructions, because it trashes or uses randomly some other floating point register than the one specified in the instruction word on loads and stores.
The instruction "fldw 0(addr),%fr22L" (and the other fldw/fstw instructions) encode the target register (%fr22) in the rightmost 5 bits of the instruction word. The 7th rightmost bit of the instruction word defines if the left or right half of %fr22 should be used.
While processing unaligned address accesses, the FR3() define is used to extract the offset into the local floating-point register set. But the calculation in FR3() was buggy, so that for example instead of %fr22, register %fr12 [((22 * 2) & 0x1f) = 12] was used.
This bug has been since forever in the parisc kernel and I wonder why it wasn't detected earlier. Interestingly I noticed this bug just because the libime debian package failed to build on *native* hardware, while it successfully built in qemu.
This patch corrects the bitshift and masking calculation in FR3().
--- arch/parisc/kernel/unaligned.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/unaligned.c +1 -1
@@ -120,7 +120,7 @@#define R1 (i) (((i)>>21)&0x1f)#define R2 (i) (((i)>>16)&0x1f)#define R3 (i) ((i)&0x1f) -#define FR3 (i) ((((i)<<1)&0x1f)|(((i)>>6)&1)) +#define FR3 (i) ((((i)&0x1f)<<1)|(((i)>>6)&1))#define IM (i,n) (((i)>>1&((1<<(n-1))-1))|((i)&1?((0-1L)<<(n-1)):0))#define IM5_2 (i) IM((i)>>16,5)#define IM5_3 (i) IM((i),5)
Greg Kroah-Hartman
maintainerPATCH 2/31 xfrm: fix refcount leak in __xfrm_policy_check()
In reply to Greg Kroah-HartmanFrom: Xin Xiong <[email protected]>
[ Upstream commit 9c9cb23e00ddf45679b21b4dacc11d1ae7961ebe ]
The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object pols[1] fails, the function simply returns 0, forgetting to decrement the reference count of pols[0], which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks.
Fix it by decreasing the reference count of pols[0] in that path.
--- net/xfrm/xfrm_policy.c | 1 + 1 file changed, 1 insertion(+)
net/xfrm/xfrm_policy.c +1 -0
@@ -2538,6 +2538,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,if (pols[1 ]) {if (IS_ERR (pols[1 ])) {XFRM_INC_STATS (net,LINUX_MIB_XFRMINPOLERROR ); +xfrm_pol_put (pols[0 ]);return 0 ; } pols[1 ]->curlft.use_time =get_seconds ();
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 3/31 af_key: Do not call xfrm_probe_algs in parallel
In reply to Greg Kroah-HartmanFrom: Herbert Xu <[email protected]>
[ Upstream commit ba953a9d89a00c078b85f4b190bc1dde66fe16b5 ]
When namespace support was added to xfrm/afkey, it caused the previously single-threaded call to xfrm_probe_algs to become multi-threaded. This is buggy and needs to be fixed with a mutex.
--- net/key/af_key.c | 3 +++ 1 file changed, 3 insertions(+)
net/key/af_key.c +3 -0
@@ -1724,9 +1724,12 @@ static int pfkey_register(struct sock *sk, struct sk_buff *skb, const struct sad pfk->registered |= (1 <<hdr->sadb_msg_satype); } +mutex_lock (&pfkey_mutex);xfrm_probe_algs (); supp_skb =compose_sadb_supported (hdr,GFP_KERNEL | __GFP_ZERO); +mutex_unlock (&pfkey_mutex); +if (!supp_skb) {if (hdr->sadb_msg_satype !=SADB_SATYPE_UNSPEC ) pfk->registered &= ~(1 <<hdr->sadb_msg_satype);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 4/31 rose: check NULL rose_loopback_neigh->loopback
In reply to Greg Kroah-HartmanFrom: Bernard Pidoux <[email protected]>
[ Upstream commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ]
Commit 3b3fd068c56e3fbea30090859216a368398e39bf added NULL check for rose_loopback_neigh->dev in rose_loopback_timer() but omitted to check rose_loopback_neigh->loopback.
It thus prevents *all* rose connect.
The reason is that a special rose_neigh loopback has a NULL device.
/proc/net/rose_neigh illustrates it via rose_neigh_show() function :
[...]
seq_printf(seq, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu",
rose_neigh->number, (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(buf, &rose_neigh->callsign), rose_neigh->dev ? rose_neigh->dev->name : "???", rose_neigh->count,
/proc/net/rose_neigh displays special rose_loopback_neigh->loopback as callsign RSLOOP-0:
addr callsign dev count use mode restart t0 tf digipeaters
00001 RSLOOP-0 ??? 1 2 DCE yes 0 0
By checking rose_loopback_neigh->loopback, rose_rx_call_request() is called even in case rose_loopback_neigh->dev is NULL. This repairs rose connections.
Verification with rose client application FPAC:
FPAC-Node v 4.1.3 (built Aug 5 2022) for LINUX (help = h) F6BVP-4 (Commands = ?) : u
Users - AX.25 Level 2 sessions :
Port Callsign Callsign AX.25 state ROSE state NetRom status axudp F6BVP-5 -> F6BVP-9 Connected Connected ---------
--- net/rose/rose_loopback.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/rose/rose_loopback.c +2 -1
@@ -99,7 +99,8 @@ static void rose_loopback_timer(unsigned long param) }if (frametype ==ROSE_CALL_REQUEST ) { -if (!rose_loopback_neigh->dev) { +if (!rose_loopback_neigh->dev && + !rose_loopback_neigh->loopback) {kfree_skb (skb);continue ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 5/31 bonding: 802.3ad: fix no transmission of LACPDUs
In reply to Greg Kroah-HartmanFrom: Jonathan Toppins <[email protected]>
[ Upstream commit d745b5062ad2b5da90a5e728d7ca884fc07315fd ]
This is caused by the global variable ad_ticks_per_sec being zero as demonstrated by the reproducer script discussed below. This causes all timer values in __ad_timer_to_ticks to be zero, resulting in the periodic timer to never fire.
To reproduce:
Run the script in tools/testing/selftests/drivers/net/bonding/bond-break-lacpdu-tx.sh which puts bonding into a state where it never transmits LACPDUs.
line 44: ip link add fbond type bond mode 4 miimon 200 \
xmit_hash_policy 1 ad_actor_sys_prio 65535 lacp_rate fast
setting bond param: ad_actor_sys_prio
given:
params.ad_actor_system = 0
call stack:
bond_option_ad_actor_sys_prio()
-> bond_3ad_update_ad_actor_settings()
-> set ad.system.sys_priority = bond->params.ad_actor_sys_prio
-> ad.system.sys_mac_addr = bond->dev->dev_addr; because
params.ad_actor_system == 0
results:
ad.system.sys_mac_addr = bond->dev->dev_addrline 48: ip link set fbond address 52:54:00:3B:7C:A6 setting bond MAC addr
call stack:
bond->dev->dev_addr = new_mac
line 52: ip link set fbond type bond ad_actor_sys_prio 65535 setting bond param: ad_actor_sys_prio
given:
params.ad_actor_system = 0
call stack:
bond_option_ad_actor_sys_prio()
-> bond_3ad_update_ad_actor_settings()
-> set ad.system.sys_priority = bond->params.ad_actor_sys_prio
-> ad.system.sys_mac_addr = bond->dev->dev_addr; because
params.ad_actor_system == 0
results:
ad.system.sys_mac_addr = bond->dev->dev_addrline 60: ip link set veth1-bond down master fbond
given:
params.ad_actor_system = 0
params.mode = BOND_MODE_8023AD
ad.system.sys_mac_addr == bond->dev->dev_addr
call stack:
bond_enslave
-> bond_3ad_initialize(); because first slave
-> if ad.system.sys_mac_addr != bond->dev->dev_addr
returnresults:
Nothing is run in bond_3ad_initialize() because dev_addr equals sys_mac_addr leaving the global ad_ticks_per_sec zero as it is never initialized anywhere else.
The if check around the contents of bond_3ad_initialize() is no longer needed due to commit 5ee14e6d336f ("bonding: 3ad: apply ad_actor settings changes immediately") which sets ad.system.sys_mac_addr if any one of the bonding parameters whos set function calls bond_3ad_update_ad_actor_settings(). This is because if ad.system.sys_mac_addr is zero it will be set to the current bond mac address, this causes the if check to never be true.
--- drivers/net/bonding/bond_3ad.c | 38 ++++++++++++++-------------------- 1 file changed, 16 insertions(+), 22 deletions(-)
drivers/net/bonding/bond_3ad.c +16 -22
@@ -1941,30 +1941,24 @@ void bond_3ad_initiate_agg_selection(struct bonding *bond, int timeout)*/ void bond_3ad_initialize (struct bonding *bond,u16 tick_resolution) { -/* check that the bond is not initialized yet */ -if (!MAC_ADDRESS_EQUAL (&(BOND_AD_INFO (bond).system.sys_mac_addr), - bond->dev->dev_addr)) { - -BOND_AD_INFO (bond).aggregator_identifier =0 ; - -BOND_AD_INFO (bond).system.sys_priority = - bond->params.ad_actor_sys_prio; -if (is_zero_ether_addr (bond->params.ad_actor_system)) -BOND_AD_INFO (bond).system.sys_mac_addr = - *((struct mac_addr *)bond->dev->dev_addr); -else -BOND_AD_INFO (bond).system.sys_mac_addr = - *((struct mac_addr *)bond->params.ad_actor_system); +BOND_AD_INFO (bond).aggregator_identifier =0 ; +BOND_AD_INFO (bond).system.sys_priority = + bond->params.ad_actor_sys_prio; +if (is_zero_ether_addr (bond->params.ad_actor_system)) +BOND_AD_INFO (bond).system.sys_mac_addr = + *((struct mac_addr *)bond->dev->dev_addr); +else +BOND_AD_INFO (bond).system.sys_mac_addr = + *((struct mac_addr *)bond->params.ad_actor_system); -/* initialize how many times this module is called in one -* second (should be about every 100ms) -*/ - ad_ticks_per_sec = tick_resolution; +/* initialize how many times this module is called in one +* second (should be about every 100ms) +*/ + ad_ticks_per_sec = tick_resolution; -bond_3ad_initiate_agg_selection (bond, -AD_AGGREGATOR_SELECTION_TIMER * - ad_ticks_per_sec); - } +bond_3ad_initiate_agg_selection (bond, +AD_AGGREGATOR_SELECTION_TIMER * + ad_ticks_per_sec); }/**
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 6/31 netfilter: nft_payload: report ERANGE for too long offset and length
In reply to Greg Kroah-HartmanFrom: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 94254f990c07e9ddf1634e0b727fab821c3b5bf9 ]
Instead of offset and length are truncation to u8, report ERANGE.
--- net/netfilter/nft_payload.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
net/netfilter/nft_payload.c +8 -2
@@ -287,6 +287,7 @@ nft_payload_select_ops(const struct nft_ctx *ctx, {enum nft_payload_bases base;unsigned int offset, len; +int err; if (tb[NFTA_PAYLOAD_BASE] == NULL || tb[NFTA_PAYLOAD_OFFSET] == NULL ||
@@ -312,8 +313,13 @@ nft_payload_select_ops(const struct nft_ctx *ctx,if (tb[NFTA_PAYLOAD_DREG ] ==NULL )return ERR_PTR (-EINVAL ); - offset =ntohl (nla_get_be32 (tb[NFTA_PAYLOAD_OFFSET ])); - len =ntohl (nla_get_be32 (tb[NFTA_PAYLOAD_LEN ])); + err =nft_parse_u32_check (tb[NFTA_PAYLOAD_OFFSET ],U8_MAX , &offset); +if (err <0 ) +return ERR_PTR (err); + + err =nft_parse_u32_check (tb[NFTA_PAYLOAD_LEN ],U8_MAX , &len); +if (err <0 ) +return ERR_PTR (err);if (len <=4 &&is_power_of_2 (len) &&IS_ALIGNED (offset, len) && base !=NFT_PAYLOAD_LL_HEADER )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 7/31 ratelimit: Fix data-races in ___ratelimit().
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 6bae8ceb90ba76cdba39496db936164fa672b9be ]
While reading rs->interval and rs->burst, they can be changed concurrently via sysctl (e.g. net_ratelimit_state). Thus, we need to add READ_ONCE() to their readers.
--- lib/ratelimit.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
lib/ratelimit.c +9 -3
@@ -27,10 +27,16 @@*/ int ___ratelimit (struct ratelimit_state *rs,const char *func) { +/* Paired with WRITE_ONCE() in .proc_handler(). +* Changing two values seperately could be inconsistent +* and some message could be lost. (See: net_ratelimit_state). +*/ +int interval =READ_ONCE (rs->interval); +int burst =READ_ONCE (rs->burst);unsigned long flags;int ret; -if (!rs->interval) +if (!interval)return 1 ;/*
@@ -45,7 +51,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)if (!rs->begin) rs->begin = jiffies; -if (time_is_before_jiffies (rs->begin + rs->interval)) { +if (time_is_before_jiffies (rs->begin + interval)) {if (rs->missed) {if (!(rs->flags &RATELIMIT_MSG_ON_RELEASE )) { printk_deferred(KERN_WARNING
@@ -57,7 +63,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func) rs->begin = jiffies; rs->printed =0 ; } -if (rs->burst && rs->burst > rs->printed) { +if (burst && burst > rs->printed) { rs->printed++; ret =1 ; }else {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 8/31 net: Fix a data-race around sysctl_tstamp_allow_data.
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
[ Upstream commit d2154b0afa73c0159b2856f875c6b4fe7cf6a95e ]
While reading sysctl_tstamp_allow_data, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
--- net/core/skbuff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/skbuff.c +1 -1
@@ -3905,7 +3905,7 @@ static bool skb_may_tx_timestamp(struct sock *sk, bool tsonly) {bool ret; -if (likely (sysctl_tstamp_allow_data || tsonly)) +if (likely (READ_ONCE (sysctl_tstamp_allow_data) || tsonly))return true;read_lock_bh (&sk->sk_callback_lock);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 9/31 net: Fix a data-race around sysctl_net_busy_poll.
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
[ Upstream commit c42b7cddea47503411bfb5f2f93a4154aaffa2d9 ]
While reading sysctl_net_busy_poll, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
--- include/net/busy_poll.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/busy_poll.h +1 -1
@@ -39,7 +39,7 @@ extern unsigned int sysctl_net_busy_poll __read_mostly;static inline bool net_busy_loop_on (void ) { -return sysctl_net_busy_poll; +return READ_ONCE (sysctl_net_busy_poll); }static inline u64 busy_loop_us_clock (void )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 10/31 net: Fix a data-race around sysctl_net_busy_read.
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
[ Upstream commit e59ef36f0795696ab229569c153936bfd068d21c ]
While reading sysctl_net_busy_read, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
--- net/core/sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/sock.c +1 -1
@@ -2508,7 +2508,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)#ifdef CONFIG_NET_RX_BUSY_POLL sk->sk_napi_id =0 ; - sk->sk_ll_usec = sysctl_net_busy_read; + sk->sk_ll_usec =READ_ONCE (sysctl_net_busy_read);#endif sk->sk_max_pacing_rate = ~0U ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 11/31 net: Fix a data-race around sysctl_somaxconn.
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 3c9ba81d72047f2e81bb535d42856517b613aba7 ]
While reading sysctl_somaxconn, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
--- net/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/socket.c +1 -1
@@ -1403,7 +1403,7 @@ SYSCALL_DEFINE2(listen, int, fd, int, backlog) sock =sockfd_lookup_light (fd, &err, &fput_needed);if (sock) { - somaxconn =sock_net (sock->sk)->core.sysctl_somaxconn; + somaxconn =READ_ONCE (sock_net (sock->sk)->core.sysctl_somaxconn);if ((unsigned int )backlog > somaxconn) backlog = somaxconn;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 12/31 ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter
In reply to Greg Kroah-HartmanFrom: Jacob Keller <[email protected]>
[ Upstream commit 25d7a5f5a6bb15a2dae0a3f39ea5dda215024726 ]
The ixgbe_ptp_start_cyclecounter is intended to be called whenever the cyclecounter parameters need to be changed.
Since commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices"), this function has cleared the SYSTIME registers and reset the TSAUXC DISABLE_SYSTIME bit.
While these need to be cleared during ixgbe_ptp_reset, it is wrong to clear them during ixgbe_ptp_start_cyclecounter. This function may be called during both reset and link status change. When link changes, the SYSTIME counter is still operating normally, but the cyclecounter should be updated to account for the possibly changed parameters.
Clearing SYSTIME when link changes causes the timecounter to jump because the cycle counter now reads zero.
Extract the SYSTIME initialization out to a new function and call this during ixgbe_ptp_reset. This prevents the timecounter adjustment and avoids an unnecessary reset of the current time.
This also restores the original SYSTIME clearing that occurred during ixgbe_ptp_reset before the commit above.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 59 +++++++++++++++----- 1 file changed, 46 insertions(+), 13 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +46 -13
@@ -1080,7 +1080,6 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapter *adapter)struct cyclecounter cc;unsigned long flags;u32 incval =0 ; -u32 tsauxc =0 ;u32 fuse0 =0 ;/* For some of the boards below this mask is technically incorrect.
@@ -1115,18 +1114,6 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapter *adapter)case ixgbe_mac_x550em_a:case ixgbe_mac_X550: cc.read = ixgbe_ptp_read_X550; - -/* enable SYSTIME counter */ -IXGBE_WRITE_REG (hw,IXGBE_SYSTIMR ,0 ); -IXGBE_WRITE_REG (hw,IXGBE_SYSTIML ,0 ); -IXGBE_WRITE_REG (hw,IXGBE_SYSTIMH ,0 ); - tsauxc =IXGBE_READ_REG (hw,IXGBE_TSAUXC ); -IXGBE_WRITE_REG (hw,IXGBE_TSAUXC , - tsauxc & ~IXGBE_TSAUXC_DISABLE_SYSTIME ); -IXGBE_WRITE_REG (hw,IXGBE_TSIM ,IXGBE_TSIM_TXTS ); -IXGBE_WRITE_REG (hw,IXGBE_EIMS ,IXGBE_EIMS_TIMESYNC ); - -IXGBE_WRITE_FLUSH (hw);break ;case ixgbe_mac_X540: cc.read = ixgbe_ptp_read_82599;
@@ -1158,6 +1145,50 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapter *adapter)spin_unlock_irqrestore (&adapter->tmreg_lock, flags); } +/** +* ixgbe_ptp_init_systime - Initialize SYSTIME registers +* @adapter: the ixgbe private board structure +* +* Initialize and start the SYSTIME registers. +*/ +static void ixgbe_ptp_init_systime (struct ixgbe_adapter *adapter) +{ +struct ixgbe_hw *hw = &adapter->hw; +u32 tsauxc; + +switch (hw->mac.type) { +case ixgbe_mac_X550EM_x: +case ixgbe_mac_x550em_a: +case ixgbe_mac_X550: + tsauxc =IXGBE_READ_REG (hw,IXGBE_TSAUXC ); + +/* Reset SYSTIME registers to 0 */ +IXGBE_WRITE_REG (hw,IXGBE_SYSTIMR ,0 ); +IXGBE_WRITE_REG (hw,IXGBE_SYSTIML ,0 ); +IXGBE_WRITE_REG (hw,IXGBE_SYSTIMH ,0 ); + +/* Reset interrupt settings */ +IXGBE_WRITE_REG (hw,IXGBE_TSIM ,IXGBE_TSIM_TXTS ); +IXGBE_WRITE_REG (hw,IXGBE_EIMS ,IXGBE_EIMS_TIMESYNC ); + +/* Activate the SYSTIME counter */ +IXGBE_WRITE_REG (hw,IXGBE_TSAUXC , + tsauxc & ~IXGBE_TSAUXC_DISABLE_SYSTIME ); +break ; +case ixgbe_mac_X540: +case ixgbe_mac_82599EB: +/* Reset SYSTIME registers to 0 */ +IXGBE_WRITE_REG (hw,IXGBE_SYSTIML ,0 ); +IXGBE_WRITE_REG (hw,IXGBE_SYSTIMH ,0 ); +break ; +default : +/* Other devices aren't supported */ +return ; + }; + +IXGBE_WRITE_FLUSH (hw); +} +/** * ixgbe_ptp_reset * @adapter: the ixgbe private board structure
@@ -1184,6 +1215,8 @@ void ixgbe_ptp_reset(struct ixgbe_adapter *adapter)ixgbe_ptp_start_cyclecounter (adapter); +ixgbe_ptp_init_systime (adapter); +spin_lock_irqsave (&adapter->tmreg_lock, flags);timecounter_init (&adapter->hw_tc, &adapter->hw_cc,ktime_to_ns (ktime_get_real ()));
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 13/31 btrfs: check if root is readonly while setting security xattr
In reply to Greg Kroah-HartmanFrom: Goldwyn Rodrigues <[email protected]>
commit b51111271b0352aa596c5ae8faf06939e91b3b68 upstream.
For a filesystem which has btrfs read-only property set to true, all write operations including xattr should be denied. However, security xattr can still be changed even if btrfs ro property is true.
This happens because xattr_permission() does not have any restrictions on security.*, system.* and in some cases trusted.* from VFS and the decision is left to the underlying filesystem. See comments in xattr_permission() for more details.
This patch checks if the root is read-only before performing the set xattr operation.
Testcase:
DEV=/dev/vdb
MNT=/mnt
mkfs.btrfs -f $DEV
mount $DEV $MNT
echo "file one" > $MNT/f1
setfattr -n "security.one" -v 2 $MNT/f1
btrfs property set /mnt ro true
setfattr -n "security.one" -v 1 $MNT/f1
umount $MNT
--- fs/btrfs/xattr.c | 3 +++ 1 file changed, 3 insertions(+)
fs/btrfs/xattr.c +3 -0
@@ -375,6 +375,9 @@ static int btrfs_xattr_handler_get(const struct dentry *unused, struct inode *inode, const char *name, void *buffer, size_t size) { + if (btrfs_root_readonly(BTRFS_I(inode)->root)) + return -EROFS; + name = xattr_full_name(handler, name);return __btrfs_getxattr (inode, name, buffer, size); }
Greg Kroah-Hartman
maintainerPATCH 14/31 loop: Check for overflow while configuring loop
In reply to Greg Kroah-HartmanFrom: Siddh Raman Pant <[email protected]>
commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 upstream.
The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset.
loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).
The function directly copies offset from info to the device as follows (See line 980 of loop.c):
lo->lo_offset = info->lo_offset;
This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has:
WARN_ON_ONCE(iter->iomap.offset > iter->pos);
Thus, check for negative value during loop_set_status_from_info().
Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
--- drivers/block/loop.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/block/loop.c +5 -0
@@ -1202,6 +1202,11 @@ loop_get_status(struct loop_device *lo, info->lo_rdevice =huge_encode_dev (lo->lo_device ? stat.rdev : stat.dev); info->lo_offset = lo->lo_offset; info->lo_sizelimit = lo->lo_sizelimit; + +/* loff_t vars have been assigned __u64 */ +if (lo->lo_offset <0 || lo->lo_sizelimit <0 ) +return -EOVERFLOW ; + info->lo_flags = lo->lo_flags;memcpy (info->lo_file_name, lo->lo_file_name,LO_NAME_SIZE );memcpy (info->lo_crypt_name, lo->lo_crypt_name,LO_NAME_SIZE );
Greg Kroah-Hartman
maintainerPATCH 15/31 asm-generic: sections: refactor memory_intersects
In reply to Greg Kroah-HartmanFrom: Quanyang Wang <[email protected]>
commit 0c7d7cc2b4fe2e74ef8728f030f0f1674f9f6aee upstream.
There are two problems with the current code of memory_intersects:
First, it doesn't check whether the region (begin, end) falls inside the region (virt, vend), that is (virt < begin && vend > end).
The second problem is if vend is equal to begin, it will return true but this is wrong since vend (virt + size) is not the last address of the memory region but (virt + size -1) is. The wrong determination will trigger the misreporting when the function check_for_illegal_area calls memory_intersects to check if the dma region intersects with stext region.
The misreporting is as below (stext is at 0x80100000):
WARNING: CPU: 0 PID: 77 at kernel/dma/debug.c:1073 check_for_illegal_area+0x130/0x168 DMA-API: chipidea-usb2 e0002000.usb: device driver maps memory from kernel text or rodata [addr=800f0000] [len=65536] Modules linked in: CPU: 1 PID: 77 Comm: usb-storage Not tainted 5.19.0-yocto-standard #5 Hardware name: Xilinx Zynq Platform unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0xb0/0x198 __warn from warn_slowpath_fmt+0x80/0xb4 warn_slowpath_fmt from check_for_illegal_area+0x130/0x168 check_for_illegal_area from debug_dma_map_sg+0x94/0x368 debug_dma_map_sg from __dma_map_sg_attrs+0x114/0x128 __dma_map_sg_attrs from dma_map_sg_attrs+0x18/0x24 dma_map_sg_attrs from usb_hcd_map_urb_for_dma+0x250/0x3b4 usb_hcd_map_urb_for_dma from usb_hcd_submit_urb+0x194/0x214 usb_hcd_submit_urb from usb_sg_wait+0xa4/0x118 usb_sg_wait from usb_stor_bulk_transfer_sglist+0xa0/0xec usb_stor_bulk_transfer_sglist from usb_stor_bulk_srb+0x38/0x70 usb_stor_bulk_srb from usb_stor_Bulk_transport+0x150/0x360 usb_stor_Bulk_transport from usb_stor_invoke_transport+0x38/0x440 usb_stor_invoke_transport from usb_stor_control_thread+0x1e0/0x238 usb_stor_control_thread from kthread+0xf8/0x104 kthread from ret_from_fork+0x14/0x2c
Refactor memory_intersects to fix the two problems above.
Before the 1d7db834a027e ("dma-debug: use memory_intersects() directly"), memory_intersects is called only by printk_late_init:
printk_late_init -> init_section_intersects ->memory_intersects.
There were few places where memory_intersects was called.
When commit 1d7db834a027e ("dma-debug: use memory_intersects() directly") was merged and CONFIG_DMA_API_DEBUG is enabled, the DMA subsystem uses it to check for an illegal area and the calltrace above is triggered.
--- include/asm-generic/sections.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
include/asm-generic/sections.h +5 -2
@@ -87,7 +87,7 @@ static inline bool memory_contains(void/** * memory_intersects - checks if the region occupied by an object intersects * with another memory region -* @begin: virtual address of the beginning of the memory regien +* @begin: virtual address of the beginning of the memory region * @end: virtual address of the end of the memory region * @virt: virtual address of the memory object * @size: size of the memory object
@@ -100,7 +100,10 @@ static inline bool memory_intersects(voi {void *vend = virt + size; -return (virt >= begin && virt < end) || (vend >= begin && vend < end); +if (virt < end && vend > begin) +return true; + +return false; }/**
Greg Kroah-Hartman
maintainerPATCH 16/31 mm/hugetlb: fix hugetlb not supporting softdirty tracking
In reply to Greg Kroah-HartmanFrom: David Hildenbrand <[email protected]>
commit f96f7a40874d7c746680c0b9f57cef2262ae551f upstream.
Patch series "mm/hugetlb: fix write-fault handling for shared mappings", v2.
I observed that hugetlb does not support/expect write-faults in shared mappings that would have to map the R/O-mapped page writable -- and I found two case where we could currently get such faults and would erroneously map an anon page into a shared mapping.
Reproducers part of the patches.
I propose to backport both fixes to stable trees. The first fix needs a small adjustment.
This patch (of 2):
Staring at hugetlb_wp(), one might wonder where all the logic for shared mappings is when stumbling over a write-protected page in a shared mapping. In fact, there is none, and so far we thought we could get away with that because e.g., mprotect() should always do the right thing and map all pages directly writable.
Looks like we were wrong:
--------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <sys/mman.h>
#define HUGETLB_SIZE (2 * 1024 * 1024u)
static void clear_softdirty(void)
{
int fd = open("/proc/self/clear_refs", O_WRONLY);
const char *ctrl = "4";
int ret;
if (fd < 0) {
fprintf(stderr, "open(clear_refs) failed\n");
exit(1);
}
ret = write(fd, ctrl, strlen(ctrl));
if (ret != strlen(ctrl)) {
fprintf(stderr, "write(clear_refs) failed\n");
exit(1);
}
close(fd);}
int main(int argc, char **argv)
{
char *map;
int fd;
fd = open("/dev/hugepages/tmp", O_RDWR | O_CREAT);
if (!fd) {
fprintf(stderr, "open() failed\n");
return -errno;
}
if (ftruncate(fd, HUGETLB_SIZE)) {
fprintf(stderr, "ftruncate() failed\n");
return -errno;
}
map = mmap(NULL, HUGETLB_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (map == MAP_FAILED) {
fprintf(stderr, "mmap() failed\n");
return -errno;
}
*map = 0;
if (mprotect(map, HUGETLB_SIZE, PROT_READ)) {
fprintf(stderr, "mmprotect() failed\n");
return -errno;
}
clear_softdirty();
if (mprotect(map, HUGETLB_SIZE, PROT_READ|PROT_WRITE)) {
fprintf(stderr, "mmprotect() failed\n");
return -errno;
}
*map = 0;
return 0; }
--------------------------------------------------------------------------
Above test fails with SIGBUS when there is only a single free hugetlb page.
# echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # ./test Bus error (core dumped)
And worse, with sufficient free hugetlb pages it will map an anonymous page into a shared mapping, for example, messing up accounting during unmap and breaking MAP_SHARED semantics:
# echo 2 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # ./test # cat /proc/meminfo | grep HugePages_ HugePages_Total: 2 HugePages_Free: 1 HugePages_Rsvd: 18446744073709551615 HugePages_Surp: 0
Reason in this particular case is that vma_wants_writenotify() will return "true", removing VM_SHARED in vma_set_page_prot() to map pages write-protected. Let's teach vma_wants_writenotify() that hugetlb does not support softdirty tracking.
--- mm/mmap.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
mm/mmap.c +6 -2
@@ -1593,8 +1593,12 @@ int vma_wants_writenotify(struct vm_area pgprot_val(vm_pgprot_modify(vm_page_prot, vm_flags)))return 0 ; -/* Do we need to track softdirty? */ -if (IS_ENABLED (CONFIG_MEM_SOFT_DIRTY ) && !(vm_flags &VM_SOFTDIRTY )) +/* +* Do we need to track softdirty? hugetlb does not support softdirty +* tracking yet. +*/ +if (IS_ENABLED (CONFIG_MEM_SOFT_DIRTY ) && !(vm_flags &VM_SOFTDIRTY ) && + !is_vm_hugetlb_page (vma))return 1 ;/* Specialty mapping? */
Greg Kroah-Hartman
maintainerPATCH 17/31 mm: Force TLB flush for PFNMAP mappings before unlink_file_vma()
In reply to Greg Kroah-HartmanFrom: Jann Horn <[email protected]>
commit b67fbebd4cf980aecbcc750e1462128bffe8ae15 upstream.
Some drivers rely on having all VMAs through which a PFN might be accessible listed in the rmap for correctness.
However, on X86, it was possible for a VMA with stale TLB entries to not be listed in the rmap.
This was fixed in mainline with
commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"), but that commit relies on preceding refactoring in
commit 18ba064e42df3 ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation") and commit 1e9fdf21a4339 ("mmu_gather: Remove per arch tlb_{start,end}_vma()").
This patch provides equivalent protection without needing that refactoring, by forcing a TLB flush between removing PTEs in unmap_vmas() and the call to unlink_file_vma() in free_pgtables().
--- mm/mmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
mm/mmap.c +12 -0
@@ -2529,6 +2529,18 @@ static void unmap_region(struct mm_structlb_gather_mmu (&tlb, mm, start, end);update_hiwater_rss (mm);unmap_vmas (&tlb, vma, start, end); + +/* +* Ensure we have no stale TLB entries by the time this mapping is +* removed from the rmap. +* Note that we don't have to worry about nested flushes here because +* we're holding the mm semaphore for removing the mapping - so any +* concurrent flush in this region has to be coming through the rmap, +* and we synchronize against that using the rmap lock. +*/ +if ((vma->vm_flags & (VM_PFNMAP |VM_MIXEDMAP )) !=0 ) +tlb_flush_mmu (&tlb); +free_pgtables (&tlb, vma, prev ? prev->vm_end :FIRST_USER_ADDRESS , next ? next->vm_start :USER_PGTABLES_CEILING );tlb_finish_mmu (&tlb, start, end);
Greg Kroah-Hartman
maintainerPATCH 18/31 s390/mm: do not trigger write fault when vma does not allow VM_WRITE
In reply to Greg Kroah-HartmanFrom: Gerald Schaefer <[email protected]>
commit 41ac42f137080bc230b5882e3c88c392ab7f2d32 upstream.
For non-protection pXd_none() page faults in do_dat_exception(), we call do_exception() with access == (VM_READ | VM_WRITE | VM_EXEC). In do_exception(), vma->vm_flags is checked against that before calling handle_mm_fault().
Since commit 92f842eac7ee3 ("[S390] store indication fault optimization"), we call handle_mm_fault() with FAULT_FLAG_WRITE, when recognizing that it was a write access. However, the vma flags check is still only checking against (VM_READ | VM_WRITE | VM_EXEC), and therefore also calling handle_mm_fault() with FAULT_FLAG_WRITE in cases where the vma does not allow VM_WRITE.
Fix this by changing access check in do_exception() to VM_WRITE only, when recognizing write access.
--- arch/s390/mm/fault.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/s390/mm/fault.c +3 -1
@@ -409,7 +409,9 @@ static inline int do_exception(struct pt flags =FAULT_FLAG_ALLOW_RETRY |FAULT_FLAG_KILLABLE ;if (user_mode (regs)) flags |=FAULT_FLAG_USER ; -if (access ==VM_WRITE || (trans_exc_code & store_indication) ==0x400 ) +if ((trans_exc_code & store_indication) ==0x400 ) + access =VM_WRITE ; +if (access ==VM_WRITE ) flags |=FAULT_FLAG_WRITE ;down_read (&mm->mmap_sem);
Greg Kroah-Hartman
maintainerPATCH 19/31 x86/cpu: Add Tiger Lake to Intel family
In reply to Greg Kroah-HartmanFrom: Gayatri Kammela <[email protected]>
commit 6e1c32c5dbb4b90eea8f964c2869d0bde050dbe0 upstream.
Add the model numbers/CPUIDs of Tiger Lake mobile and desktop to the Intel family.
--- arch/x86/include/asm/intel-family.h | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/include/asm/intel-family.h +3 -0
@@ -70,6 +70,9 @@#define INTEL_FAM6_ALDERLAKE 0x97#define INTEL_FAM6_ALDERLAKE_L 0x9A +#define INTEL_FAM6_TIGERLAKE_L 0x8C +#define INTEL_FAM6_TIGERLAKE 0x8D +/* "Small Core" Processors (Atom) */ #define INTEL_FAM6_ATOM_BONNELL 0x1C/* Diamondville, Pineview */
Greg Kroah-Hartman
maintainerPATCH 20/31 x86/bugs: Add "unknown" reporting for MMIO Stale Data
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 7df548840c496b0141fb2404b889c346380c2b22 upstream.
Older Intel CPUs that are not in the affected processor list for MMIO Stale Data vulnerabilities currently report "Not affected" in sysfs, which may not be correct. Vulnerability status for these older CPUs is unknown.
Add known-not-affected CPUs to the whitelist. Report "unknown" mitigation status for CPUs that are not in blacklist, whitelist and also don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware immunity to MMIO Stale Data vulnerabilities.
Mitigation is not deployed when the status is unknown.
[ bp: Massage, fixup. ]
--- Documentation/hw-vuln/processor_mmio_stale_data.rst | 14 ++++++++ arch/x86/include/asm/cpufeatures.h | 1 arch/x86/kernel/cpu/bugs.c | 14 +++++++- arch/x86/kernel/cpu/common.c | 34 +++++++++++++------- 4 files changed, 50 insertions(+), 13 deletions(-)
Documentation/hw-vuln/processor_mmio_stale_data.rst +14 -0
@@ -230,6 +230,20 @@ The possible values in this file are: * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigation is enabled. + * - 'Unknown: No mitigations' + - The processor vulnerability status is unknown because it is + out of Servicing period. Mitigation is not attempted. + +Definitions: +------------ + +Servicing period: The process of providing functional and security updates to +Intel processors or platforms, utilizing the Intel Platform Update (IPU) +process or other similar mechanisms. + +End of Servicing Updates (ESU): ESU is the date at which Intel will no +longer provide Servicing, such as through IPU or other similar update +processes. ESU dates will typically be aligned to end of quarter. If the processor is vulnerable then the following information is appended to the above information:
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -363,5 +363,6 @@#define X86_BUG_ITLB_MULTIHIT X86_BUG(23)/* CPU may incur MCE during certain page attribute changes */ #define X86_BUG_SRBDS X86_BUG(24)/* CPU may leak RNG bits if not mitigated */ #define X86_BUG_MMIO_STALE_DATA X86_BUG(25)/* CPU is affected by Processor MMIO Stale Data vulnerabilities */ +#define X86_BUG_MMIO_UNKNOWN X86_BUG(26)/* CPU is too old and its MMIO Stale Data status is unknown */ #endif /* _ASM_X86_CPUFEATURES_H */
arch/x86/kernel/cpu/bugs.c +12 -2
@@ -395,7 +395,8 @@ static void __init mmio_select_mitigatiou64 ia32_cap;if (!boot_cpu_has_bug (X86_BUG_MMIO_STALE_DATA ) || -cpu_mitigations_off ()) { +boot_cpu_has_bug (X86_BUG_MMIO_UNKNOWN ) || +cpu_mitigations_off ()) { mmio_mitigation =MMIO_MITIGATION_OFF ;return ; }
@@ -500,6 +501,8 @@ out:pr_info ("TAA: %s\n" , taa_strings[taa_mitigation]);if (boot_cpu_has_bug (X86_BUG_MMIO_STALE_DATA ))pr_info ("MMIO Stale Data: %s\n" , mmio_strings[mmio_mitigation]); +else if (boot_cpu_has_bug (X86_BUG_MMIO_UNKNOWN )) +pr_info ("MMIO Stale Data: Unknown: No mitigations\n" ); }static void __init md_clear_select_mitigation (void )
@@ -1824,6 +1827,9 @@ static ssize_t tsx_async_abort_show_statstatic ssize_t mmio_stale_data_show_state (char *buf) { +if (boot_cpu_has_bug (X86_BUG_MMIO_UNKNOWN )) +return sysfs_emit (buf,"Unknown: No mitigations\n" ); +if (mmio_mitigation ==MMIO_MITIGATION_OFF )return sysfs_emit (buf,"%s\n" , mmio_strings[mmio_mitigation]);
@@ -1934,6 +1940,7 @@ static ssize_t cpu_show_common(struct dereturn srbds_show_state (buf);case X86_BUG_MMIO_STALE_DATA : +case X86_BUG_MMIO_UNKNOWN :return mmio_stale_data_show_state (buf);default :
@@ -1990,6 +1997,9 @@ ssize_t cpu_show_srbds(struct device *dessize_t cpu_show_mmio_stale_data (struct device *dev,struct device_attribute *attr,char *buf) { -return cpu_show_common (dev, attr, buf,X86_BUG_MMIO_STALE_DATA ); +if (boot_cpu_has_bug (X86_BUG_MMIO_UNKNOWN )) +return cpu_show_common (dev, attr, buf,X86_BUG_MMIO_UNKNOWN ); +else +return cpu_show_common (dev, attr, buf,X86_BUG_MMIO_STALE_DATA ); }#endif
arch/x86/kernel/cpu/common.c +23 -11
@@ -899,6 +899,7 @@ static void identify_cpu_without_cpuid(s#define MSBDS_ONLY BIT(5)#define NO_SWAPGS BIT(6)#define NO_ITLB_MULTIHIT BIT(7) +#define NO_MMIO BIT(8)#define VULNWL (_vendor, _family, _model, _whitelist) \ { X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
@@ -916,6 +917,11 @@ static const __initconst struct x86_cpu_VULNWL (NSC ,5 ,X86_MODEL_ANY ,NO_SPECULATION ),/* Intel Family 6 */ +VULNWL_INTEL (TIGERLAKE ,NO_MMIO ), +VULNWL_INTEL (TIGERLAKE_L ,NO_MMIO ), +VULNWL_INTEL (ALDERLAKE ,NO_MMIO ), +VULNWL_INTEL (ALDERLAKE_L ,NO_MMIO ), +VULNWL_INTEL (ATOM_SALTWELL ,NO_SPECULATION |NO_ITLB_MULTIHIT ),VULNWL_INTEL (ATOM_SALTWELL_TABLET ,NO_SPECULATION |NO_ITLB_MULTIHIT ), VULNWL_INTEL(ATOM_SALTWELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT),
@@ -933,9 +939,9 @@ static const __initconst struct x86_cpu_VULNWL_INTEL (ATOM_AIRMONT_MID ,NO_L1TF |MSBDS_ONLY |NO_SWAPGS |NO_ITLB_MULTIHIT ), -VULNWL_INTEL (ATOM_GOLDMONT ,NO_MDS |NO_L1TF |NO_SWAPGS |NO_ITLB_MULTIHIT ), -VULNWL_INTEL (ATOM_GOLDMONT_X ,NO_MDS |NO_L1TF |NO_SWAPGS |NO_ITLB_MULTIHIT ), - VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT), +VULNWL_INTEL (ATOM_GOLDMONT ,NO_MDS |NO_L1TF |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ), +VULNWL_INTEL (ATOM_GOLDMONT_X ,NO_MDS |NO_L1TF |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ), + VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),/* * Technically, swapgs isn't serializing on AMD (despite it previously
@@ -946,13 +952,13 @@ static const __initconst struct x86_cpu_*/ /* AMD Family 0xf - 0x12 */ -VULNWL_AMD (0x0f ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT ), -VULNWL_AMD (0x10 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT ), -VULNWL_AMD (0x11 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT ), -VULNWL_AMD (0x12 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT ), +VULNWL_AMD (0x0f ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ), +VULNWL_AMD (0x10 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ), +VULNWL_AMD (0x11 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ), +VULNWL_AMD (0x12 ,NO_MELTDOWN |NO_SSB |NO_L1TF |NO_MDS |NO_SWAPGS |NO_ITLB_MULTIHIT |NO_MMIO ),/* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */ - VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT), + VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO), {} };
@@ -1092,10 +1098,16 @@ static void __init cpu_set_bug_bits(stru* Affected CPU list is generally enough to enumerate the vulnerability, * but for virtualization case check for ARCH_CAP MSR bits also, VMM may * not want the guest to enumerate the bug. +* +* Set X86_BUG_MMIO_UNKNOWN for CPUs that are neither in the blacklist, +* nor in the whitelist and also don't enumerate MSR ARCH_CAP MMIO bits. */ -if (cpu_matches (cpu_vuln_blacklist,MMIO ) && - !arch_cap_mmio_immune (ia32_cap)) -setup_force_cpu_bug (X86_BUG_MMIO_STALE_DATA ); +if (!arch_cap_mmio_immune (ia32_cap)) { +if (cpu_matches (cpu_vuln_blacklist,MMIO )) +setup_force_cpu_bug (X86_BUG_MMIO_STALE_DATA ); +else if (!cpu_matches (cpu_vuln_whitelist,NO_MMIO )) +setup_force_cpu_bug (X86_BUG_MMIO_UNKNOWN ); + }if (cpu_matches (cpu_vuln_whitelist,NO_MELTDOWN ))return ;
Greg Kroah-Hartman
maintainerPATCH 21/31 kbuild: Fix include path in scripts/Makefile.modpost
In reply to Greg Kroah-HartmanFrom: Jing Leng <[email protected]>
commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream.
When building an external module, if users don't need to separate the compilation output and source code, they run the following command:
"make -C $(LINUX_SRC_DIR) M=$(PWD)". At this point, "$(KBUILD_EXTMOD)" and "$(src)" are the same.
If they need to separate them, they run "make -C $(KERNEL_SRC_DIR) O=$(KERNEL_OUT_DIR) M=$(OUT_DIR) src=$(PWD)". Before running the command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to prevent compilation failure.
So the kernel should change the included path to avoid the copy operation.
[masahiro: I do not think "M=$(OUT_DIR) src=$(PWD)" is the official way, but this patch is a nice clean up anyway.]
--- scripts/Makefile.modpost | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
scripts/Makefile.modpost +1 -2
@@ -50,8 +50,7 @@ obj := $(KBUILD_EXTMOD) src := $(obj) # Include the module's Makefile to find KBUILD_EXTRA_SYMBOLS -include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \ - $(KBUILD_EXTMOD)/Kbuild, $(KBUILD_EXTMOD)/Makefile) +include $(if $(wildcard $(src)/Kbuild), $(src)/Kbuild, $(src)/Makefile) endif include scripts/Makefile.lib
Greg Kroah-Hartman
maintainerPATCH 22/31 Bluetooth: L2CAP: Fix build errors in some archs
In reply to Greg Kroah-HartmanFrom: Luiz Augusto von Dentz <[email protected]>
commit b840304fb46cdf7012722f456bce06f151b3e81b upstream.
This attempts to fix the follow errors:
In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:420:16: note: in expansion of macro
'__underlying_memcmp'
420 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15:./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:420:16: note: in expansion of macro
'__underlying_memcmp'
420 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~--- net/bluetooth/l2cap_core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
net/bluetooth/l2cap_core.c +5 -5
@@ -1826,11 +1826,11 @@ static struct l2cap_chan *l2cap_global_c src_match = !bacmp (&c->src, src); dst_match = !bacmp (&c->dst, dst);if (src_match && dst_match) { - c =l2cap_chan_hold_unless_zero (c); -if (c) { -read_unlock (&chan_list_lock); -return c; - } +if (!l2cap_chan_hold_unless_zero (c)) +continue ; + +read_unlock (&chan_list_lock); +return c; }/* Closest match */
Greg Kroah-Hartman
maintainerPATCH 23/31 media: pvrusb2: fix memory leak in pvr_probe
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
commit 945a9a8e448b65bec055d37eba58f711b39f66f0 upstream.
The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns.
Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface.
--- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/usb/pvrusb2/pvrusb2-hdw.c +1 -0
@@ -2656,6 +2656,7 @@ struct pvr2_hdw *pvr2_hdw_create(structdel_timer_sync (&hdw->encoder_run_timer);del_timer_sync (&hdw->encoder_wait_timer);flush_work (&hdw->workpoll); +v4l2_device_unregister (&hdw->v4l2_dev);usb_free_urb (hdw->ctl_read_urb);usb_free_urb (hdw->ctl_write_urb);kfree (hdw->ctl_read_buffer);
Greg Kroah-Hartman
maintainerPATCH 24/31 HID: hidraw: fix memory leak in hidraw_release()
In reply to Greg Kroah-HartmanFrom: Karthik Alapati <[email protected]>
commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream.
Free the buffered reports before deleting the list entry.
BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
hex dump (first 32 bytes):
64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline]
[<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
[<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
[<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
[<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
[<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
[<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
[<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
[<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
[<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline]
[<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
[<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline]
[<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
[<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
[<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline]
[<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline]
[<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
[<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
[<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
[<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
[<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
[<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
[<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554--- drivers/hid/hidraw.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/hid/hidraw.c +3 -0
@@ -354,10 +354,13 @@ static int hidraw_release(struct inode *unsigned int minor =iminor (inode);struct hidraw_list *list = file->private_data;unsigned long flags; +int i;mutex_lock (&minors_lock);spin_lock_irqsave (&hidraw_table[minor]->list_lock, flags); +for (i = list->tail; i < list->head; i++) +kfree (list->buffer[i].value);list_del (&list->node);spin_unlock_irqrestore (&hidraw_table[minor]->list_lock, flags);kfree (list);
Greg Kroah-Hartman
maintainerPATCH 25/31 fbdev: fb_pm2fb: Avoid potential divide by zero error
In reply to Greg Kroah-HartmanFrom: Letu Ren <[email protected]>
commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream.
In do_fb_ioctl() of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through fb_set_var() and info->fbops->fb_check_var() which could may be pm2fb_check_var(). Along the path, var->pixclock won't be modified. This function checks whether reciprocal of var->pixclock is too high. If var->pixclock is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below.
divide error in pm2fb_check_var
Call Trace: <TASK> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
--- drivers/video/fbdev/pm2fb.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/video/fbdev/pm2fb.c +5 -0
@@ -614,6 +614,11 @@ static int pm2fb_check_var(struct fb_varreturn -EINVAL ; } +if (!var->pixclock) { +DPRINTK ("pixclock is zero\n" ); +return -EINVAL ; + } +if (PICOS2KHZ (var->pixclock) >PM2_MAX_PIXCLOCK ) {DPRINTK ("pixclock too high (%ldKHz)\n" ,PICOS2KHZ (var->pixclock));
Greg Kroah-Hartman
maintainerPATCH 26/31 ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
In reply to Greg Kroah-HartmanFrom: Yang Jihong <[email protected]>
commit c3b0f72e805f0801f05fa2aa52011c4bfc694c44 upstream.
ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails:
register_ftrace_function
ftrace_startup
__register_ftrace_function
...
add_ftrace_ops(&ftrace_ops_list, ops)
...
...
ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
... return 0 // ops is in the ftrace_ops_list.
When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:unregister_ftrace_function
ftrace_shutdown
if (unlikely(ftrace_disabled))
return -ENODEV; // return here, __unregister_ftrace_function is not executed,
// as a result, ops is still in the ftrace_ops_list
__unregister_ftrace_function
...If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer:
is_ftrace_trampoline
ftrace_ops_trampoline
do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!
Syzkaller reports as follows:
[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Therefore, when ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list.
--- kernel/trace/ftrace.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
kernel/trace/ftrace.c +10 -0
@@ -2737,6 +2737,16 @@ static int ftrace_startup(struct ftrace_ftrace_startup_enable (command); +/* +* If ftrace is in an undefined state, we just remove ops from list +* to prevent the NULL pointer, instead of totally rolling it back and +* free trampoline, because those actions could cause further damage. +*/ +if (unlikely (ftrace_disabled)) { +__unregister_ftrace_function (ops); +return -ENODEV ; + } + ops->flags &= ~FTRACE_OPS_FL_ADDING ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 27/31 arm64: map FDT as RW for early_init_dt_scan()
In reply to Greg Kroah-HartmanFrom: Hsin-Yi Wang <[email protected]>
commit e112b032a72c78f15d0c803c5dc6be444c2e6c66 upstream.
Currently in arm64, FDT is mapped to RO before it's passed to early_init_dt_scan(). However, there might be some codes (eg. commit "fdt: add support for rng-seed") that need to modify FDT during init. Map FDT to RO after early fixups are done.
--- arch/arm64/include/asm/mmu.h | 2 +- arch/arm64/kernel/kaslr.c | 5 +---- arch/arm64/kernel/setup.c | 9 ++++++++- arch/arm64/mm/mmu.c | 15 +-------------- 4 files changed, 11 insertions(+), 20 deletions(-)
arch/arm64/include/asm/mmu.h +1 -1
@@ -90,7 +90,7 @@ extern void init_mem_pgprot(void);extern void create_pgd_mapping (struct mm_struct *mm,phys_addr_t phys,unsigned long virt,phys_addr_t size,pgprot_t prot,bool allow_block_mappings); -extern void *fixmap_remap_fdt (phys_addr_t dt_phys); +extern void *fixmap_remap_fdt (phys_addr_t dt_phys,int *size,pgprot_t prot);#endif /* !__ASSEMBLY__ */ #endif
arch/arm64/kernel/kaslr.c +1 -4
@@ -65,9 +65,6 @@ out:return default_cmdline; } -extern void *__init __fixmap_remap_fdt (phys_addr_t dt_phys,int *size, -pgprot_t prot); -/* * This routine will be executed with the kernel mapped at its default virtual * address, and if it returns successfully, the kernel will be remapped, and
@@ -96,7 +93,7 @@ u64 __init kaslr_early_init(u64 dt_phys,* attempt at mapping the FDT in setup_machine() */ early_fixmap_init (); - fdt =__fixmap_remap_fdt (dt_phys, &size,PAGE_KERNEL ); + fdt =fixmap_remap_fdt (dt_phys, &size,PAGE_KERNEL );if (!fdt)return 0 ;
arch/arm64/kernel/setup.c +8 -1
@@ -178,7 +178,11 @@ static void __init smp_build_mpidr_hash(static void __init setup_machine_fdt (phys_addr_t dt_phys) { -void *dt_virt =fixmap_remap_fdt (dt_phys); +int size; +void *dt_virt =fixmap_remap_fdt (dt_phys, &size,PAGE_KERNEL ); + +if (dt_virt) +memblock_reserve (dt_phys, size);if (!dt_virt || !early_init_dt_scan (dt_virt)) { pr_crit("\n"
@@ -191,6 +195,9 @@ static void __init setup_machine_fdt(phycpu_relax (); } +/* Early fixups are done, map the FDT as read-only now */ +fixmap_remap_fdt (dt_phys, &size,PAGE_KERNEL_RO ); +dump_stack_set_arch_desc ("%s (DT)" ,of_flat_dt_get_machine_name ()); }
arch/arm64/mm/mmu.c +1 -14
@@ -718,7 +718,7 @@ void __set_fixmap(enum fixed_addresses i } } -void *__init __fixmap_remap_fdt (phys_addr_t dt_phys,int *size,pgprot_t prot) +void *__init fixmap_remap_fdt (phys_addr_t dt_phys,int *size,pgprot_t prot) {const u64 dt_virt_base =__fix_to_virt (FIX_FDT );int offset;
@@ -771,19 +771,6 @@ void *__init __fixmap_remap_fdt(phys_addreturn dt_virt; } -void *__init fixmap_remap_fdt (phys_addr_t dt_phys) -{ -void *dt_virt; -int size; - - dt_virt =__fixmap_remap_fdt (dt_phys, &size,PAGE_KERNEL_RO ); -if (!dt_virt) -return NULL ; - -memblock_reserve (dt_phys, size); -return dt_virt; -} -int __init arch_ioremap_pud_supported (void ) {/*
Greg Kroah-Hartman
maintainerPATCH 28/31 s390/hypfs: avoid error message under KVM
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
[ Upstream commit 7b6670b03641ac308aaa6fa2e6f964ac993b5ea3 ]
When booting under KVM the following error messages are issued:
hypfs.7f5705: The hardware system does not support hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=-61
Demote the severity of first message from "error" to "info" and issue the second message only in other error cases.
--- arch/s390/hypfs/hypfs_diag.c | 2 +- arch/s390/hypfs/inode.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/s390/hypfs/hypfs_diag.c +1 -1
@@ -436,7 +436,7 @@ __init int hypfs_diag_init(void)int rc;if (diag204_probe ()) { -pr_err ("The hardware system does not support hypfs\n" ); +pr_info ("The hardware system does not support hypfs\n" );return -ENODATA ; }if (diag204_info_type ==DIAG204_INFO_EXT ) {
arch/s390/hypfs/inode.c +1 -1
@@ -493,9 +493,9 @@ static int __init hypfs_init(void)hypfs_vm_exit (); fail_hypfs_diag_exit:hypfs_diag_exit (); +pr_err ("Initialization of hypfs failed with rc=%i\n" , rc); fail_dbfs_exit:hypfs_dbfs_exit (); -pr_err ("Initialization of hypfs failed with rc=%i\n" , rc);return rc; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 29/31 netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
[ Upstream commit aa5762c34213aba7a72dc58e70601370805fa794 ]
NF_CONNTRACK_PROCFS was marked obsolete in commit 54b07dca68557b09 ("netfilter: provide config option to disable ancient procfs parts") in v3.3.
--- net/netfilter/Kconfig | 1 - 1 file changed, 1 deletion(-)
net/netfilter/Kconfig +0 -1
@@ -96,7 +96,6 @@ config NF_CONNTRACK_ZONES config NF_CONNTRACK_PROCFS bool "Supply CT list in procfs (OBSOLETE)" - default y depends on PROC_FS ---help--- This option enables for the list of known conntrack entries
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 30/31 mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse
In reply to Greg Kroah-HartmanFrom: Jann Horn <[email protected]>
commit 2555283eb40df89945557273121e9393ef9b542b upstream.
anon_vma->degree tracks the combined number of child anon_vmas and VMAs that use the anon_vma as their ->anon_vma.
anon_vma_clone() then assumes that for any anon_vma attached to src->anon_vma_chain other than src->anon_vma, it is impossible for it to be a leaf node of the VMA tree, meaning that for such VMAs ->degree is elevated by 1 because of a child anon_vma, meaning that if ->degree equals 1 there are no VMAs that use the anon_vma as their ->anon_vma.
This assumption is wrong because the ->degree optimization leads to leaf nodes being abandoned on anon_vma_clone() - an existing anon_vma is reused and no new parent-child relationship is created. So it is possible to reuse an anon_vma for one VMA while it is still tied to another VMA.
This is an issue because is_mergeable_anon_vma() and its callers assume that if two VMAs have the same ->anon_vma, the list of anon_vmas attached to the VMAs is guaranteed to be the same. When this assumption is violated, vma_merge() can merge pages into a VMA that is not attached to the corresponding anon_vma, leading to dangling page->mapping pointers that will be dereferenced during rmap walks.
Fix it by separately tracking the number of child anon_vmas and the number of VMAs using the anon_vma as their ->anon_vma.
--- include/linux/rmap.h | 7 +++++-- mm/rmap.c | 31 +++++++++++++++++-------------- 2 files changed, 22 insertions(+), 16 deletions(-)
include/linux/rmap.h +5 -2
@@ -37,12 +37,15 @@ struct anon_vma {atomic_t refcount;/* -* Count of child anon_vmas and VMAs which points to this anon_vma. +* Count of child anon_vmas. Equals to the count of all anon_vmas that +* have ->parent pointing to this one, including itself. * * This counter is used for making decision about reusing anon_vma * instead of forking new one. See comments in function anon_vma_clone. */ -unsigned degree; +unsigned long num_children; +/* Count of VMAs whose ->anon_vma pointer points to this object. */ +unsigned long num_active_vmas;struct anon_vma *parent;/* Parent of this anon_vma */
mm/rmap.c +17 -14
@@ -78,7 +78,8 @@ static inline struct anon_vma *anon_vma_ anon_vma =kmem_cache_alloc (anon_vma_cachep,GFP_KERNEL );if (anon_vma) {atomic_set (&anon_vma->refcount,1 ); - anon_vma->degree =1 ;/* Reference for first vma */ + anon_vma->num_children =0 ; + anon_vma->num_active_vmas =0 ; anon_vma->parent = anon_vma;/* * Initialise the anon_vma root to point to itself. If called
@@ -187,6 +188,7 @@ int anon_vma_prepare(struct vm_area_stru anon_vma =anon_vma_alloc ();if (unlikely (!anon_vma)) goto out_enomem_free_avc; + anon_vma->num_children++;/* self-parent link for new root */ allocated = anon_vma; }
@@ -196,8 +198,7 @@ int anon_vma_prepare(struct vm_area_struif (likely (!vma->anon_vma)) { vma->anon_vma = anon_vma;anon_vma_chain_link (vma, avc, anon_vma); -/* vma reference or self-parent link for new root */ - anon_vma->degree++; + anon_vma->num_active_vmas++; allocated =NULL ; avc =NULL ; }
@@ -276,19 +277,19 @@ int anon_vma_clone(struct vm_area_structanon_vma_chain_link (dst, avc, anon_vma);/* -* Reuse existing anon_vma if its degree lower than two, -* that means it has no vma and only one anon_vma child. +* Reuse existing anon_vma if it has no vma and only one +* anon_vma child. * -* Do not chose parent anon_vma, otherwise first child -* will always reuse it. Root anon_vma is never reused: +* Root anon_vma is never reused: * it has self-parent reference and at least one child. */ -if (!dst->anon_vma && anon_vma != src->anon_vma && - anon_vma->degree <2 ) +if (!dst->anon_vma && + anon_vma->num_children <2 && + anon_vma->num_active_vmas ==0 ) dst->anon_vma = anon_vma; }if (dst->anon_vma) - dst->anon_vma->degree++; + dst->anon_vma->num_active_vmas++;unlock_anon_vma_root (root);return 0 ;
@@ -338,6 +339,7 @@ int anon_vma_fork(struct vm_area_struct anon_vma =anon_vma_alloc ();if (!anon_vma) goto out_error; + anon_vma->num_active_vmas++; avc =anon_vma_chain_alloc (GFP_KERNEL );if (!avc) goto out_error_free_anon_vma;
@@ -358,7 +360,7 @@ int anon_vma_fork(struct vm_area_struct vma->anon_vma = anon_vma;anon_vma_lock_write (anon_vma);anon_vma_chain_link (vma, avc, anon_vma); - anon_vma->parent->degree++; + anon_vma->parent->num_children++;anon_vma_unlock_write (anon_vma);return 0 ;
@@ -390,7 +392,7 @@ void unlink_anon_vmas(struct vm_area_str* to free them outside the lock. */ if (RB_EMPTY_ROOT (&anon_vma->rb_root)) { - anon_vma->parent->degree--; + anon_vma->parent->num_children--;continue ; }
@@ -398,7 +400,7 @@ void unlink_anon_vmas(struct vm_area_stranon_vma_chain_free (avc); }if (vma->anon_vma) - vma->anon_vma->degree--; + vma->anon_vma->num_active_vmas--;unlock_anon_vma_root (root);/*
@@ -409,7 +411,8 @@ void unlink_anon_vmas(struct vm_area_strlist_for_each_entry_safe (avc, next, &vma->anon_vma_chain, same_vma) {struct anon_vma *anon_vma = avc->anon_vma; -VM_WARN_ON (anon_vma->degree); +VM_WARN_ON (anon_vma->num_children); +VM_WARN_ON (anon_vma->num_active_vmas);put_anon_vma (anon_vma);list_del (&avc->same_vma);
Greg Kroah-Hartman
maintainerPATCH 31/31 kprobes: dont call disarm_kprobe() for disabled kprobes
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
commit 9c80e79906b4ca440d09e7f116609262bb747909 upstream.
The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue.
1. Write 0 to /sys/kernel/debug/kprobes/enabled.
# echo 0 > /sys/kernel/debug/kprobes/enabled
2. Run execsnoop. At this time, one kprobe is disabled.
# /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe.
# echo 1 > /sys/kernel/debug/kprobes/enabled
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().
# fg /usr/share/bcc/tools/execsnoop ^C
Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
aggregated kprobe.list -> kprobe.list -.
^ |
'.__.'In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup.
cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the
infinite loop with RCU.
/usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,
and __get_valid_kprobe() is stuck in the loop.
To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes.
[0]
Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)
WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/sched.h:2056 (discriminator 1) kernel/task_work.c:179 (discriminator 1)) exit_to_user_mode_prepare (./include/linux/resume_user_mode.h:49 kernel/entry/common.c:169 kernel/entry/common.c:201) syscall_exit_to_user_mode (./arch/x86/include/asm/jump_label.h:55 ./arch/x86/include/asm/nospec-branch.h:384 ./arch/x86/include/asm/entry-common.h:94 kernel/entry/common.c:133 kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:87) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7fe7ff210654 Code: 15 79 89 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb be 0f 1f 00 8b 05 9a cd 20 00 48 63 ff 85 c0 75 11 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3a f3 c3 48 83 ec 18 48 89 7c 24 08 e8 34 fc RSP: 002b:00007ffdbd1d3538 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000008 RCX: 00007fe7ff210654 RDX: 0000000000000000 RSI: 0000000000002401 RDI: 0000000000000008 RBP: 0000000000000000 R08: 94ae31d6fda838a4 R0900007fe8001c9d30 R10: 00007ffdbd1d34b0 R11: 0000000000000246 R12: 00007ffdbd1d3600 R13: 0000000000000000 R14: fffffffffffffffc R15: 00007ffdbd1d3560 </TASK>
--- kernel/kprobes.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
kernel/kprobes.c +6 -4
@@ -1616,12 +1616,14 @@ static struct kprobe *__disable_kprobe(s/* Try to disarm and disable this/parent probe */ if (p == orig_p ||aggr_kprobe_disabled (orig_p)) {/* -* If kprobes_all_disarmed is set, orig_p -* should have already been disarmed, so -* skip unneed disarming process. +* Don't be lazy here. Even if 'kprobes_all_disarmed' +* is false, 'orig_p' might not have been armed yet. +* Note arm_all_kprobes() __tries__ to arm all kprobes +* on the best effort basis. */ -if (!kprobes_all_disarmed) +if (!kprobes_all_disarmed && !kprobe_disabled (orig_p))disarm_kprobe (orig_p, true); + orig_p->flags |=KPROBE_FLAG_DISABLED ; } }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +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.9.327-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.9.327-rc1-g24fc65df6e8a
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +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.9.327-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +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.9.327-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.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 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +0000. Anything received after that time might be too late.
Build results:
total: 164 pass: 164 fail: 0 Qemu test results: total: 394 pass: 394 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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 Sun, 04 Sep 2022 12:13:47 +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.9.327-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.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.9.327-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.9.y
* git commit: 24fc65df6e8a89f1c917a8aef1636e5c17901edb
* git describe: v4.9.326-32-g24fc65df6e8a
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.326-32-g24fc65df6e8a
## No test Regressions (compared to v4.9.326)
## No metric Regressions (compared to v4.9.326)
## No test Fixes (compared to v4.9.326)
## No metric Fixes (compared to v4.9.326)
## Test result summary
total: 78542, pass: 67880, fail: 721, skip: 9575, xfail: 366
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 250 total, 245 passed, 5 failed
* arm64: 50 total, 43 passed, 7 failed
* i386: 26 total, 25 passed, 1 failed
* mips: 30 total, 30 passed, 0 failed
* parisc: 12 total, 0 passed, 12 failed
* powerpc: 36 total, 16 passed, 20 failed
* s390: 12 total, 9 passed, 3 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 45 total, 44 passed, 1 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libhugetlbfs
* 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-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.9.327 release. There are 31 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-4.9.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