This is a note to let you know that I've just added the patch titled
ipv6: flowlabel: do not leave opt->tot_len with garbage
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 21 Oct 2017 12:26:23 -0700
Subject: ipv6: flowlabel: do not leave opt->tot_len with garbage
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 864e2a1f8aac05effac6063ce316b480facb46ff ]
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.
If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.
Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.
Fix is to properly set tot_len in fl6_merge_options()
At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().
[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x358/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -315,6 +315,7 @@ struct ipv6_txoptions *fl6_merge_options
}
opt_space->dst1opt = fopt->dst1opt;
opt_space->opt_flen = fopt->opt_flen;
+ opt_space->tot_len = fopt->tot_len;
return opt_space;
}
EXPORT_SYMBOL_GPL(fl6_merge_options);
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1201,11 +1201,11 @@ static int ip6_setup_cork(struct sock *s
if (WARN_ON(v6_cork->opt))
return -EINVAL;
- v6_cork->opt = kzalloc(opt->tot_len, sk->sk_allocation);
+ v6_cork->opt = kzalloc(sizeof(*opt), sk->sk_allocation);
if (unlikely(!v6_cork->opt))
return -ENOBUFS;
- v6_cork->opt->tot_len = opt->tot_len;
+ v6_cork->opt->tot_len = sizeof(*opt);
v6_cork->opt->opt_flen = opt->opt_flen;
v6_cork->opt->opt_nflen = opt->opt_nflen;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:23:27 +0800
Subject: ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f8d20b46ce55cf40afb30dcef6d9288f7ef46d9b ]
The similar fix in patch 'ipip: only increase err_count for some
certain type icmp in ipip_err' is needed for ip6gre_err.
In Jianlin's case, udp netperf broke even when receiving a TooBig
icmpv6 packet.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_gre.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -409,13 +409,16 @@ static void ip6gre_err(struct sk_buff *s
case ICMPV6_DEST_UNREACH:
net_dbg_ratelimited("%s: Path to destination invalid or inactive!\n",
t->parms.name);
- break;
+ if (code != ICMPV6_PORT_UNREACH)
+ break;
+ return;
case ICMPV6_TIME_EXCEED:
if (code == ICMPV6_EXC_HOPLIMIT) {
net_dbg_ratelimited("%s: Too small hop limit or routing loop in tunnel!\n",
t->parms.name);
+ break;
}
- break;
+ return;
case ICMPV6_PARAMPROB:
teli = 0;
if (code == ICMPV6_HDR_FIELD)
@@ -431,13 +434,13 @@ static void ip6gre_err(struct sk_buff *s
net_dbg_ratelimited("%s: Recipient unable to parse tunneled packet!\n",
t->parms.name);
}
- break;
+ return;
case ICMPV6_PKT_TOOBIG:
mtu = be32_to_cpu(info) - offset;
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
t->dev->mtu = mtu;
- break;
+ return;
}
if (time_before(jiffies, t->err_time + IP6TUNNEL_ERR_TIMEO))
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 62b9fa2c436ffd9b87e6ed81df7f86c29fee092b which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/soreuseport-fix-initialization-race.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-4.9/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.9/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/sctp-full-support-for-ipv6-ip_nonlocal_bind-ip_freebind.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.9/gso-fix-payload-length-when-gso_size-is-zero.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
queue-4.9/ip6_gre-update-dst-pmtu-if-dev-mtu-has-been-updated-by-toobig-in-__gre6_xmit.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
queue-4.9/tap-double-free-in-error-path-in-tap_open.patch
queue-4.9/ppp-fix-race-in-ppp-device-destruction.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.9/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
queue-4.9/netlink-do-not-set-cb_running-if-dump-s-start-errs.patch
queue-4.9/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
queue-4.9/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-4.9/usb-usbtest-fix-null-pointer-dereference.patch
queue-4.9/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 2eb85ef18c6570e8a59643cd8d5a66122461b1fc which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-3.18/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-3.18/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-3.18/mac80211-use-constant-time-comparison-with-keys.patch
queue-3.18/revert-ceph-unlock-dangling-spinlock-in-try_flush_caps.patch
queue-3.18/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-3.18/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-3.18/usb-usbtest-fix-null-pointer-dereference.patch
Hi Aditya,
My problem is fixed with this patch. WILC1000 connects to AP,
IP is retrieved from DHCP server and ping works. You can add my
Tested-by: Claudiu Beznea <claudiu.beznea(a)microchip.com>
Thanks,
Claudiu
On 03.11.2017 10:56, Aditya Shankar wrote:
> Commit 46949b48568b ("staging: wilc1000: New cfg packet
> format in handle_set_wfi_drv_handler") updated the frame
> format sent from host to the firmware. The code to update
> the bssid offset in the new frame was part of a second
> patch in the series which did not make it in and thus
> causes connection problems after associating to an AP.
>
> This fix adds the proper offset of the bssid value in the
> Tx queue buffer to fix the connection issues.
>
> Fixes: Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler")
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Aditya Shankar <Aditya.Shankar(a)microchip.com>
> ---
> drivers/staging/wilc1000/wilc_wlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index 9addef1..f49dfa8 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count)
> char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
>
> buffer_offset = ETH_ETHERNET_HDR_OFFSET;
> - memcpy(&txb[offset + 4], bssid, 6);
> + memcpy(&txb[offset + 8], bssid, 6);
> } else {
> buffer_offset = HOST_HDR_OFFSET;
> }
>
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are three target patches for v3.10.y stable, the first of which
did not originally include a stable CC, and the latter two did not
apply due to a minor context change.
The series has been cut against v3.10.108. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Mikulas Patocka (1):
iscsi-target: fix iscsit_del_np deadlock on unload
Nicholas Bellinger (1):
iscsi-target: Fix iscsi_np reset hung task during parallel delete
drivers/target/iscsi/iscsi_target.c | 20 ++++++++------------
drivers/target/iscsi/iscsi_target_core.h | 1 +
drivers/target/iscsi/iscsi_target_login.c | 25 ++++++++++++-------------
include/target/target_core_base.h | 1 +
4 files changed, 22 insertions(+), 25 deletions(-)
--
1.8.5.3