- Feb 16, 2022
-
-
Greg Kroah-Hartman authored
commit 38ea1eac upstream. Check the size of the RNDIS_MSG_SET command given to us before attempting to respond to an invalid message size. Reported-by:
Szymon Heidrich <szymon.heidrich@gmail.com> Cc: stable@kernel.org Tested-by:
Szymon Heidrich <szymon.heidrich@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Szymon Heidrich authored
commit 75e5b484 upstream. Stall the control endpoint in case provided index exceeds array size of MAX_CONFIG_INTERFACES or when the retrieved function pointer is null. Signed-off-by:
Szymon Heidrich <szymon.heidrich@gmail.com> Cc: stable@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Udipto Goswami authored
commit 117b4e96 upstream. With CPU re-ordering on write instructions, there might be a chance that the HWO is set before the TRB is updated with the new mapped buffer address. And in the case where core is processing a list of TRBs it is possible that it fetched the TRBs when the HWO is set but before the buffer address is updated. Prevent this by adding a memory barrier before the HWO is updated to ensure that the core always process the updated TRBs. Fixes: f6bafc6a ("usb: dwc3: convert TRBs into bitshifts") Cc: stable <stable@vger.kernel.org> Reviewed-by:
Pavankumar Kondeti <quic_pkondeti@quicinc.com> Signed-off-by:
Udipto Goswami <quic_ugoswami@quicinc.com> Link: https://lore.kernel.org/r/1644207958-18287-1-git-send-email-quic_ugoswami@quicinc.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
TATSUKAWA KOSUKE (立川 江介) authored
commit c816b2e6 upstream. The poll man page says POLLRDNORM is equivalent to POLLIN when used as an event. $ man poll <snip> POLLRDNORM Equivalent to POLLIN. However, in n_tty driver, POLLRDNORM does not return until timeout even if there is terminal input, whereas POLLIN returns. The following test program works until kernel-3.17, but the test stops in poll() after commit 57087d51 ("tty: Fix spurious poll() wakeups"). [Steps to run test program] $ cc -o test-pollrdnorm test-pollrdnorm.c $ ./test-pollrdnorm foo <-- Type in something from the terminal followed by [RET]. The string should be echoed back. ------------------------< test-pollrdnorm.c >------------------------ #include <stdio.h> #include <errno.h> #include <poll.h> #include <unistd.h> void main(void) { int n; unsigned char buf[8]; struct pollfd fds[1] = {{ 0, POLLRDNORM, 0 }}; n = poll(fds, 1, -1); if (n < 0) perror("poll"); n = read(0, buf, 8); if (n < 0) perror("read"); if (n > 0) write(1, buf, n); } ------------------------------------------------------------------------ The attached patch fixes this problem. Many calls to wake_up_interruptible_poll() in the kernel source code already specify "POLLIN | POLLRDNORM". Fixes: 57087d51 ("tty: Fix spurious poll() wakeups") Cc: stable@vger.kernel.org Signed-off-by:
Kosuke Tatsukawa <tatsu-ab1@nec.com> Link: https://lore.kernel.org/r/TYCPR01MB81901C0F932203D30E452B3EA5209@TYCPR01MB8190.jpnprd01.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Borkmann authored
commit 08389d88 upstream. Add a kconfig knob which allows for unprivileged bpf to be disabled by default. If set, the knob sets /proc/sys/kernel/unprivileged_bpf_disabled to value of 2. This still allows a transition of 2 -> {0,1} through an admin. Similarly, this also still keeps 1 -> {1} behavior intact, so that once set to permanently disabled, it cannot be undone aside from a reboot. We've also added extra2 with max of 2 for the procfs handler, so that an admin still has a chance to toggle between 0 <-> 2. Either way, as an additional alternative, applications can make use of CAP_BPF that we added a while ago. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/74ec548079189e4e4dffaeb42b8987bb3c852eee.1620765074.git.daniel@iogearbox.net [fllinden@amazon.com: backported to 4.9] Signed-off-by:
Frank van der Linden <fllinden@amazon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jakob Koschel authored
commit 28cb138f upstream. in vt_setactivate an almost identical code path has been patched with array_index_nospec. In the VT_ACTIVATE path the user input is from a system call argument instead of a usercopy. For consistency both code paths should have the same mitigations applied. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. Co-developed-by:
Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by:
Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by:
Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220127144406.3589293-2-jakobkoschel@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jakob Koschel authored
commit 61cc70d9 upstream. array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. Co-developed-by:
Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by:
Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by:
Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220127144406.3589293-1-jakobkoschel@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jon Maloy authored
[ Upstream commit c7223d68 ] It would be easy to craft a message containing an illegal binding table update operation. This is handled correctly by the code, but the corresponding warning printout is not rate limited as is should be. We fix this now. Fixes: b97bf3fd ("[TIPC] Initial merge") Signed-off-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Antoine Tenart authored
[ Upstream commit 9eeabdf1 ] When uncloning an skb dst and its associated metadata, a new dst+metadata is allocated and later replaces the old one in the skb. This is helpful to have a non-shared dst+metadata attached to a specific skb. The issue is the uncloned dst+metadata is initialized with a refcount of 1, which is increased to 2 before attaching it to the skb. When tun_dst_unclone returns, the dst+metadata is only referenced from a single place (the skb) while its refcount is 2. Its refcount will never drop to 0 (when the skb is consumed), leading to a memory leak. Fix this by removing the call to dst_hold in tun_dst_unclone, as the dst+metadata refcount is already 1. Fixes: fc4099f1 ("openvswitch: Fix egress tunnel info.") Cc: Pravin B Shelar <pshelar@ovn.org> Reported-by:
Vlad Buslov <vladbu@nvidia.com> Tested-by:
Vlad Buslov <vladbu@nvidia.com> Signed-off-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Antoine Tenart authored
[ Upstream commit cfc56f85 ] When uncloning an skb dst and its associated metadata a new dst+metadata is allocated and the tunnel information from the old metadata is copied over there. The issue is the tunnel metadata has references to cached dst, which are copied along the way. When a dst+metadata refcount drops to 0 the metadata is freed including the cached dst entries. As they are also referenced in the initial dst+metadata, this ends up in UaFs. In practice the above did not happen because of another issue, the dst+metadata was never freed because its refcount never dropped to 0 (this will be fixed in a subsequent patch). Fix this by initializing the dst cache after copying the tunnel information from the old metadata to also unshare the dst cache. Fixes: d71785ff ("net: add dst_cache to ovs vxlan lwtunnel") Cc: Paolo Abeni <pabeni@redhat.com> Reported-by:
Vlad Buslov <vladbu@nvidia.com> Tested-by:
Vlad Buslov <vladbu@nvidia.com> Signed-off-by:
Antoine Tenart <atenart@kernel.org> Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eric Dumazet authored
[ Upstream commit 5611a006 ] ip[6]mr_free_table() can only be called under RTNL lock. RTNL: assertion failed at net/core/dev.c (10367) WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Modules linked in: CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4 R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000 FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4ab89f9059 Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f. RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059 RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000 RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300 R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000 R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000 </TASK> Fixes: f243e5a7 ("ipmr,ip6mr: call ip6mr_free_table() on failure path") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Cong Wang <cong.wang@bytedance.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20220208053451.2885398-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mahesh Bandewar authored
[ Upstream commit 23de0d7b ] When 803.2ad mode enables a participating port, it should update the slave-array. I have observed that the member links are participating and are part of the active aggregator while the traffic is egressing via only one member link (in a case where two links are participating). Via kprobes I discovered that slave-arr has only one link added while the other participating link wasn't part of the slave-arr. I couldn't see what caused that situation but the simple code-walk through provided me hints that the enable_port wasn't always associated with the slave-array update. Fixes: ee637714 ("bonding: Simplify the xmit function for modes that use xmit_hash") Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://lore.kernel.org/r/20220207222901.1795287-1-maheshb@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
[ Upstream commit 993d6614 ] GPIO7_IO00 is used as SD card detect. Properly describe this in the devicetree. Fixes: 40cdaa54 ("ARM: dts: imx6q-udoo: Add initial board support") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Uwe Kleine-König authored
[ Upstream commit 426aca16 ] If registering the platform driver fails, the function must not return without undoing the spi driver registration first. Fixes: c296d5f9 ("staging: fbtft: core support") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220118181338.207943-1-u.kleine-koenig@pengutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
commit 42c9b28e upstream. Currently, SD card fails to mount due to the following pinctrl error: [ 11.170000] imx23-pinctrl 80018000.pinctrl: pin SSP1_DETECT already requested by 80018000.pinctrl; cannot claim for 80010000.spi [ 11.180000] imx23-pinctrl 80018000.pinctrl: pin-65 (80010000.spi) status -22 [ 11.190000] imx23-pinctrl 80018000.pinctrl: could not request pin 65 (SSP1_DETECT) from group mmc0-pins-fixup.0 on device 80018000.pinctrl [ 11.200000] mxs-mmc 80010000.spi: Error applying setting, reverse things back Fix it by removing the MX23_PAD_SSP1_DETECT pin from the hog group as it is already been used by the mmc0-pins-fixup pinctrl group. With this change the rootfs can be mounted and the imx23-evk board can boot successfully. Cc: <stable@vger.kernel.org> Fixes: bc3875f1 ("ARM: dts: mxs: modify mx23/mx28 dts files to use pinctrl headers") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Amelie Delaunay authored
[ Upstream commit ac55d163 ] Calling dwc2_hsotg_ep_disable on ep0 (in/out) will lead to the following logs before returning -EINVAL: dwc2 49000000.usb-otg: dwc2_hsotg_ep_disable: called for ep0 dwc2 49000000.usb-otg: dwc2_hsotg_ep_disable: called for ep0 To avoid these two logs while suspending, start disabling the endpoint from the index 1, as done in dwc2_hsotg_udc_stop: /* all endpoints should be shutdown */ for (ep = 1; ep < hsotg->num_of_eps; ep++) { if (hsotg->eps_in[ep]) dwc2_hsotg_ep_disable_lock(&hsotg->eps_in[ep]->ep); if (hsotg->eps_out[ep]) dwc2_hsotg_ep_disable_lock(&hsotg->eps_out[ep]->ep); } Acked-by:
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20211207130101.270314-1-amelie.delaunay@foss.st.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
ZouMingzhe authored
[ Upstream commit a861790a ] iscsit_tpg_check_network_portal() has nested for_each loops and is supposed to return true when a match is found. However, the tpg loop will still continue after existing the tpg_np loop. If this tpg_np is not the last the match value will be changed. Break the outer loop after finding a match and make sure the np under each tpg is unique. Link: https://lore.kernel.org/r/20220111054742.19582-1-mingzhe.zou@easystack.cn Signed-off-by:
ZouMingzhe <mingzhe.zou@easystack.cn> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Olga Kornievskaia authored
[ Upstream commit 90e12a31 ] Remove the check for the zero length fs_locations reply in the xdr decoding, and instead check for that in the migration code. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Xiaoke Wang authored
[ Upstream commit fbd2057e ] kstrdup() returns NULL when some internal memory errors happen, it is better to check the return value of it so to catch the memory error in time. Signed-off-by:
Xiaoke Wang <xkernel.wang@foxmail.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Olga Kornievskaia authored
[ Upstream commit 2c52c837 ] When the bitmask of the attributes doesn't include the security label, don't bother printing it. Since the label might not be null terminated, adjust the printing format accordingly. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Guillaume Bertholon authored
This reverts commit 9f1a3c13. The upstream commit b400c2f4 ("net: axienet: Wait for PhyRstCmplt after core reset") add new instructions in the `__axienet_device_reset` function to wait until PhyRstCmplt bit is set, and return a non zero-exit value if this exceeds a timeout. However, its backported version in 4.9 (commit 9f1a3c13 ("net: axienet: Wait for PhyRstCmplt after core reset")) insert these instructions in `axienet_dma_bd_init` instead. Unlike upstream, the version of `__axienet_device_reset` currently present in branch stable/linux-4.9.y does not return an integer for error codes. Therefore fixing the backport cannot be as simple as moving the inserted instructions in the right place, and we simply revert it instead. Fixes: 9f1a3c13 ("net: axienet: Wait for PhyRstCmplt after core reset") Signed-off-by:
Guillaume Bertholon <guillaume.bertholon@ens.fr> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guillaume Bertholon authored
The upstream commit 70256b42 ("ALSA: line6: Fix wrong altsetting for LINE6_PODHD500_1") changed the .altsetting field of the LINE6_PODHD500_1 entry in podhd_properties_table from 1 to 0. However, its backported version in stable (commit ec565611 ("ALSA: line6: Fix wrong altsetting for LINE6_PODHD500_1")) change the .altsetting field of the LINE6_PODHD500_0 entry instead. This patch resets the altsetting of LINE6_PODHD500_0 to 1, and sets the altsetting of LINE6_PODHD500_1 to 0, as wanted by the original fix. Fixes: ec565611 ("ALSA: line6: Fix wrong altsetting for LINE6_PODHD500_1") Signed-off-by:
Guillaume Bertholon <guillaume.bertholon@ens.fr> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guillaume Bertholon authored
The upstream commit 5f76895e ("serial: sh-sci: Fix late enablement of AUTORTS") inserted a new call to .set_mctrl(). However the backported version in stable (commit ad3faea0 ("serial: sh-sci: Fix late enablement of AUTORTS")) does not insert it at the same position. This patch moves the added instructions back to where they should be according to the upsteam patch. Fixes: ad3faea0 ("serial: sh-sci: Fix late enablement of AUTORTS") Signed-off-by:
Guillaume Bertholon <guillaume.bertholon@ens.fr> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guillaume Bertholon authored
The upstream commit b5d6e7ab ("Input: i8042 - add ASUS Zenbook Flip to noselftest list") inserted a new entry in the `i8042_dmi_noselftest_table` table, further patched by commit daa58c8e ("Input: i8042 - fix Pegatron C15B ID entry") to insert a missing separator. However, their backported version in stable (commit e9e8b376 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list") and commit c551d20d ("Input: i8042 - fix Pegatron C15B ID entry")) inserted this entry in `i8042_dmi_forcemux_table` instead. This patch moves the entry back into `i8042_dmi_noselftest_table`. Fixes: e9e8b376 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list") Signed-off-by:
Guillaume Bertholon <guillaume.bertholon@ens.fr> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chuck Lever authored
commit 6260d9a5 upstream. Ensure that a client cannot specify a WRITE range that falls in a byte range outside what the kernel's internal types (such as loff_t, which is signed) can represent. The kiocb iterators, invoked in nfsd_vfs_write(), should properly limit write operations to within the underlying file system's s_maxbytes. Cc: stable@vger.kernel.org Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Trond Myklebust authored
commit 468d126d upstream. For some long forgotten reason, the nfs_client cl_flags field is initialised in nfs_get_client() instead of being initialised at allocation time. This quirk was harmless until we moved the call to nfs_create_rpc_client(). Fixes: dd99e9f9 ("NFSv4: Initialise connection to the server in nfs4_alloc_client()") Cc: stable@vger.kernel.org # 4.8.x Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stefan Berger authored
commit f7333b95 upstream. The removal of ima_dir currently fails since ima_policy still exists, so remove the ima_policy file before removing the directory. Fixes: 4af4662f ("integrity: IMA policy") Signed-off-by:
Stefan Berger <stefanb@linux.ibm.com> Cc: <stable@vger.kernel.org> Acked-by:
Christian Brauner <brauner@kernel.org> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Xiaoke Wang authored
commit 83230351 upstream. audit_log_start() returns audit_buffer pointer on success or NULL on error, so it is better to check the return value of it. Fixes: 3323eec9 ("integrity: IMA as an integrity service provider") Signed-off-by:
Xiaoke Wang <xkernel.wang@foxmail.com> Cc: <stable@vger.kernel.org> Reviewed-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Feb 11, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220209191247.830371456@linuxfoundation.org Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Slade Watkins <slade@sladewatkins.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jon Maloy authored
commit 9aa422ad upstream. The function tipc_mon_rcv() allows a node to receive and process domain_record structs from peer nodes to track their views of the network topology. This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAX_MON_DOMAIN, something that may otherwise lead to a stack overflow. tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where we are reading a 32 bit message data length field into a uint16. To avert any risk of bit overflow, we add an extra sanity check for this in that function. We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer. This potential problem was identified by Eric Dumazet. This fixes CVE-2022-0435 Reported-by:
Samuel Page <samuel.page@appgate.com> Reported-by:
Eric Dumazet <edumazet@google.com> Fixes: 35c55c98 ("tipc: add neighbor monitoring framework") Signed-off-by:
Jon Maloy <jmaloy@redhat.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Reviewed-by:
Samuel Page <samuel.page@appgate.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
commit bd2db32e upstream. It was reported that the mmc host structure could be accessed after it was freed in moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer dereference. Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Cc: Xin Xiong <xiongx18@fudan.edu.cn> Cc: Xin Tan <tanxin.ctf@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Yang Li <yang.lee@linux.alibaba.com> Cc: linux-mmc@vger.kernel.org Cc: stable <stable@vger.kernel.org> Reported-by:
whitehat002 <hackyzh002@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220127071638.4057899-1-gregkh@linuxfoundation.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric W. Biederman authored
commit 24f60085 upstream. The cgroup release_agent is called with call_usermodehelper. The function call_usermodehelper starts the release_agent with a full set fo capabilities. Therefore require capabilities when setting the release_agaent. Reported-by:
Tabitha Sable <tabitha.c.sable@gmail.com> Tested-by:
Tabitha Sable <tabitha.c.sable@gmail.com> Fixes: 81a6a5cd ("Task Control Groups: automatic userspace notification of idle cgroups") Cc: stable@vger.kernel.org # v2.6.24+ Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Tejun Heo <tj@kernel.org> [mkoutny: Adjust for pre-fs_context, duplicate mount/remount check, drop log messages.] Acked-by:
Michal Koutný <mkoutny@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Feb 09, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220207103752.341184175@linuxfoundation.org Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Slade Watkins <slade@sladewatkins.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ritesh Harjani authored
commit 897026aa upstream. While running "./check -I 200 generic/475" it sometimes gives below kernel BUG(). Ideally we should not call ext4_write_inline_data() if ext4_create_inline_data() has failed. <log snip> [73131.453234] kernel BUG at fs/ext4/inline.c:223! <code snip> 212 static void ext4_write_inline_data(struct inode *inode, struct ext4_iloc *iloc, 213 void *buffer, loff_t pos, unsigned int len) 214 { <...> 223 BUG_ON(!EXT4_I(inode)->i_inline_off); 224 BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); This patch handles the error and prints out a emergency msg saying potential data loss for the given inode (since we couldn't restore the original inline_data due to some previous error). [ 9571.070313] EXT4-fs (dm-0): error restoring inline_data for inode -- potential data loss! (inode 1703982, error -30) Reported-by:
Eric Whitney <enwlinux@gmail.com> Signed-off-by:
Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/9f4cd7dfd54fa58ff27270881823d94ddf78dd07.1642416995.git.riteshh@linux.ibm.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sergey Shtylyov authored
commit dfd0dfb9 upstream. The driver overrides error codes returned by platform_get_irq_optional() to -EINVAL for some strange reason, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the proper error codes to platform driver code upwards. [ bp: Massage commit message. ] Fixes: 0d442930 ("EDAC: Add APM X-Gene SoC EDAC driver") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220124185503.6720-3-s.shtylyov@omp.ru Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sergey Shtylyov authored
commit 279eb857 upstream. The driver overrides the error codes returned by platform_get_irq() to -ENODEV for some strange reason, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the proper error codes to platform driver code upwards. [ bp: Massage commit message. ] Fixes: 71bcada8 ("edac: altera: Add Altera SDRAM EDAC support") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Dinh Nguyen <dinguyen@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220124185503.6720-2-s.shtylyov@omp.ru Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Riwen Lu authored
commit ff164ae3 upstream. There's limiting the year to 2069. When setting the rtc year to 2070, reading it returns 1970. Evaluate century starting from 19 to count the correct year. $ sudo date -s 20700106 Mon 06 Jan 2070 12:00:00 AM CST $ sudo hwclock -w $ sudo hwclock -r 1970-01-06 12:00:49.604968+08:00 Fixes: 2a4daadd ("rtc: cmos: ignore bogus century byte") Signed-off-by:
Riwen Lu <luriwen@kylinos.cn> Acked-by:
Eric Wong <e@80x24.org> Reviewed-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220106084609.1223688-1-luriwen@kylinos.cn Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> # preparation for stable Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dai Ngo authored
commit ab451ea9 upstream. From RFC 7530 Section 16.34.5: o The server has not recorded an unconfirmed { v, x, c, *, * } and has recorded a confirmed { v, x, c, *, s }. If the principals of the record and of SETCLIENTID_CONFIRM do not match, the server returns NFS4ERR_CLID_INUSE without removing any relevant leased client state, and without changing recorded callback and callback_ident values for client { x }. The current code intends to do what the spec describes above but it forgot to set 'old' to NULL resulting to the confirmed client to be expired. Fixes: 2b634821 ("nfsd: fix clid_inuse on mount with security change") Signed-off-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Bruce Fields <bfields@fieldses.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John Meneghini authored
commit 936bd034 upstream. Running tests with a debug kernel shows that bnx2fc_recv_frame() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled. [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50 [ 1391.699268] ? set_kthread_struct+0x100/0x100 [ 1391.699273] ret_from_fork+0x22/0x30 Restore the old get_cpu/put_cpu code with some modifications to reduce the size of the critical section. Link: https://lore.kernel.org/r/20220124145110.442335-1-jmeneghi@redhat.com Fixes: d576a5e8 ("bnx2fc: Improve stats update mechanism") Tested-by:
Guangwu Zhang <guazhang@redhat.com> Acked-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
John Meneghini <jmeneghi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Miaoqian Lin authored
commit fb25621d upstream. Add the missing platform_device_put() and platform_device_del() before return from pcm030_fabric_probe in the error handling case. Fixes: c912fa91 ("ASoC: fsl: register the wm9712-codec") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220127131336.30214-1-linmq006@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-