From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
From: Daniel Kobras
commit f1442d6349a2e7bb7a6134791bdc26cb776c79af upstream.
If an auth module's accept op returns SVC_CLOSE, svc_process_common()
enters a call path that does not call svc_authorise() before leaving the
function, and thus leaks a reference on the auth module's refcount. Hence
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
fields.
This is further mapped on the arm64.nopauth command-line alias.
Signed-off-by: Marc
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
fields.
This is further mapped on the arm64.nopauth command-line alias.
Signed-off-by: Marc
Hi Marc,
On 1/23/2021 6:28 AM, Catalin Marinas wrote:
On Mon, Jan 18, 2021 at 09:45:33AM +, Marc Zyngier wrote:
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
fields.
This is further mapped on the arm64.nopauth command-line alias.
Signed-off-by: Marc
On Mon, Jan 18, 2021 at 09:45:33AM +, Marc Zyngier wrote:
> In order to be able to disable Pointer Authentication at runtime,
> whether it is for testing purposes, or to work around HW issues,
> let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
> fields.
>
> This is
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
fields.
This is further mapped on the arm64.nopauth command-line alias.
Signed-off-by: Marc
In order to be able to disable Pointer Authentication at runtime,
whether it is for testing purposes, or to work around HW issues,
let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA}
fields.
This is further mapped on the arm64.nopauth command-line alias.
Signed-off-by: Marc
From: Richard Weinberger
commit 78c7d49f55d8631b67c09f9bfbe8155211a9ea06 upstream.
When removing the last reference of an inode the size of an auth node
is already part of write_len. So we must not call ubifs_add_auth_dirt().
Call it only when needed.
Cc:
Cc: Sascha Hauer
Cc: Kristof Havasi
From: Richard Weinberger
commit 78c7d49f55d8631b67c09f9bfbe8155211a9ea06 upstream.
When removing the last reference of an inode the size of an auth node
is already part of write_len. So we must not call ubifs_add_auth_dirt().
Call it only when needed.
Cc:
Cc: Sascha Hauer
Cc: Kristof Havasi
- Ursprüngliche Mail -
> Von: "Sascha Hauer"
> An: "richard"
> CC: "linux-mtd" , "linux-kernel"
> , "stable"
> , "Kristof Havasi"
> Gesendet: Dienstag, 29. September 2020 10:32:32
> Betreff: Re: [PATCH]
On Mon, Sep 28, 2020 at 09:06:12PM +0200, Richard Weinberger wrote:
> When removing the last reference of an inode the size of an auth node
> is already part of write_len. So we must not call ubifs_add_auth_dirt().
> Call it only when needed.
>
> Cc:
> Cc: Sascha Hauer
&g
When removing the last reference of an inode the size of an auth node
is already part of write_len. So we must not call ubifs_add_auth_dirt().
Call it only when needed.
Cc:
Cc: Sascha Hauer
Cc: Kristof Havasi
Fixes: 6a98bc4614de ("ubifs: Add authentication nodes to journal"
is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong
auth/policy test")
Cc: Tadeusz Struk
Cc: sta...@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Jarkko Sakkinen
Signed-off
eanup after unseal with wrong
auth/policy test")
Cc: Tadeusz Struk
Cc: sta...@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Jarkko Sakkinen
---
tools/testing/selftests/tpm2/test_smoke.sh | 5 -
1 file changed, 5 deletions(-)
On Sun, May 24, 2020 at 11:27:15PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused
From: Colin Ian King
The variable ret is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_auth.c | 2
s.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -2030,7 +2030,6 @@ gss_unwrap_resp_priv(struct rpc_task *task, struct
rpc_cred *cred,
struct xdr_buf *rcv_buf = >rq_rcv_buf;
struct kvec *head = rqstp->rq_rcv_buf.head;
struct rpc_auth *auth = cred->cr_auth;
- unsigned
s.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -2030,7 +2030,6 @@ gss_unwrap_resp_priv(struct rpc_task *task, struct
rpc_cred *cred,
struct xdr_buf *rcv_buf = >rq_rcv_buf;
struct kvec *head = rqstp->rq_rcv_buf.head;
struct rpc_auth *auth = cred->cr_auth;
- unsigned
3.16.75-rc1 review patch. If anyone has any objections, please let me know.
--
From: Xin Long
commit 25bff6d5478b2a02368097015b7d8eb727c87e16 upstream.
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk
rtw_joinbss_cmd:
drivers/staging/rtl8723bs/core/rtw_cmd.c:771:6: warning: variable auth set but
not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 6 ++
1 file changed, 2
From: Xin Long
[ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,
Here to fix it by only holding the sk when auth shkey
From: Xin Long
[ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,
Here to fix it by only holding the sk when auth shkey
From: Xin Long
[ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,
Here to fix it by only holding the sk when auth shkey
From: Xin Long
[ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,
Here to fix it by only holding the sk when auth shkey
From: Xin Long
[ Upstream commit 25bff6d5478b2a02368097015b7d8eb727c87e16 ]
Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,
Here to fix it by only holding the sk when auth shkey
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
On Wed, 22 May 2019, David Howells wrote:
> Grant Link permission to the possessers of request_key authentication keys,
> thereby allowing a daemon that is servicing upcalls to arrange things such
> that only the necessary auth key is passed to the actual service program
>
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
ook and the userspace side
manages to lose the authorisation key, the auth key and the internal
construction record (struct key_construction) can keep each other pinned.
Fix this by the following changes:
(1) Killing off the construction record and using the auth key instead.
(2) Including the operation n
ook and the userspace side
manages to lose the authorisation key, the auth key and the internal
construction record (struct key_construction) can keep each other pinned.
Fix this by the following changes:
(1) Killing off the construction record and using the auth key instead.
(2) Including the operation n
From: David Howells
[ Upstream commit 822ad64d7e46a8e2c8b8a796738d7b657cbb146d ]
In the request_key() upcall mechanism there's a dependency loop by which if
a key type driver overrides the ->request_key hook and the userspace side
manages to lose the authorisation key, the auth
From: David Howells
[ Upstream commit 822ad64d7e46a8e2c8b8a796738d7b657cbb146d ]
In the request_key() upcall mechanism there's a dependency loop by which if
a key type driver overrides the ->request_key hook and the userspace side
manages to lose the authorisation key, the auth
From: David Howells
[ Upstream commit 822ad64d7e46a8e2c8b8a796738d7b657cbb146d ]
In the request_key() upcall mechanism there's a dependency loop by which if
a key type driver overrides the ->request_key hook and the userspace side
manages to lose the authorisation key, the auth
auth
flavors and instead just always compares auth flavors.
Consider the following scenario:
You have a server with the address 192.168.1.1 and two exports /export/a
and /export/b. The first export supports `sys' and `krb5' security, the
second just `sys'.
Assume you start with no mounts from
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
In the request_key() upcall mechanism there's a dependency loop by which if
a key type driver overrides the ->request_key hook and the userspace side
manages to lose the authorisation key, the auth key and the internal
construction record (struct key_construction) can keep each other pinned.
auth
flavors and instead just always compares auth flavors.
Consider the following scenario:
You have a server with the address 192.168.1.1 and two exports /export/a
and /export/b. The first export supports `sys' and `krb5' security, the
second just `sys'.
Assume you start with no mounts from
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
auth
flavors and instead just always compares auth flavors.
Consider the following scenario:
You have a server with the address 192.168.1.1 and two exports /export/a
and /export/b. The first export supports `sys' and `krb5' security, the
second just `sys'.
Assume you start with no mounts from
auth
flavors and instead just always compares auth flavors.
Consider the following scenario:
You have a server with the address 192.168.1.1 and two exports /export/a
and /export/b. The first export supports `sys' and `krb5' security, the
second just `sys'.
Assume you start with no mounts from
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
From: Chris Perl
[ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ]
This patch removes the check from nfs_compare_mount_options to see if a
`sec' option was passed for the current mount before comparing auth
flavors and instead just always compares auth flavors.
Consider
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions and
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions and
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ]
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions
On 12/7/18 12:39 PM, Kristina Martsenko wrote:
> From: Mark Rutland
>
> To allow EL0 (and/or EL1) to use pointer authentication functionality,
> we must ensure that pointer authentication instructions and accesses to
> pointer authentication keys are not trapped to EL2.
>
> This patch ensures
From: Mark Rutland
To allow EL0 (and/or EL1) to use pointer authentication functionality,
we must ensure that pointer authentication instructions and accesses to
pointer authentication keys are not trapped to EL2.
This patch ensures that HCR_EL2 is configured appropriately when the
kernel is
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
Am Freitag, 2. November 2018, 12:11:22 CET schrieb Arnd Bergmann:
> The new authentication support causes a build failure
> when CONFIG_KEYS is disabled, so add a dependency.
>
> fs/ubifs/auth.c: In function 'ubifs_init_authentication':
> fs/ubifs/auth.c:249:16: error: implicit declaration of
Am Freitag, 2. November 2018, 12:11:22 CET schrieb Arnd Bergmann:
> The new authentication support causes a build failure
> when CONFIG_KEYS is disabled, so add a dependency.
>
> fs/ubifs/auth.c: In function 'ubifs_init_authentication':
> fs/ubifs/auth.c:249:16: error: implicit declaration of
The new authentication support causes a build failure
when CONFIG_KEYS is disabled, so add a dependency.
fs/ubifs/auth.c: In function 'ubifs_init_authentication':
fs/ubifs/auth.c:249:16: error: implicit declaration of function 'request_key';
did you mean 'request_irq'?
The new authentication support causes a build failure
when CONFIG_KEYS is disabled, so add a dependency.
fs/ubifs/auth.c: In function 'ubifs_init_authentication':
fs/ubifs/auth.c:249:16: error: implicit declaration of function 'request_key';
did you mean 'request_irq'?
3.16.60-rc1 review patch. If anyone has any objections, please let me know.
--
From: Xin Long
commit ce402f044e4e432c296f90eaabb8dbe8f3624391 upstream.
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
3.16.60-rc1 review patch. If anyone has any objections, please let me know.
--
From: Xin Long
commit ce402f044e4e432c296f90eaabb8dbe8f3624391 upstream.
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
= move_node(c, sleb, snod, wbuf);
if (err)
goto out;
+ moved = 1;
+ }
+
+ if (ubifs_authenticated(c) && moved) {
+ struct ubifs_auth_node *auth;
+
+ auth = k
= move_node(c, sleb, snod, wbuf);
if (err)
goto out;
+ moved = 1;
+ }
+
+ if (ubifs_authenticated(c) && moved) {
+ struct ubifs_auth_node *auth;
+
+ auth = k
03,7 +409,32 @@ static int move_nodes(struct ubifs_info *c, struct
> > ubifs_scan_leb *sleb)
> > continue;
> > }
> >
> > + ubifs_shash_update(c, c->jheads[GCHD].log_hash,
> > +
03,7 +409,32 @@ static int move_nodes(struct ubifs_info *c, struct
> > ubifs_scan_leb *sleb)
> > continue;
> > }
> >
> > + ubifs_shash_update(c, c->jheads[GCHD].log_hash,
> > +
snod->node, snod->len);
> +
> err = move_node(c, sleb, snod, wbuf);
> + if (err)
> + goto out;
> + moved = 1;
> + }
> +
> +
snod->node, snod->len);
> +
> err = move_node(c, sleb, snod, wbuf);
> + if (err)
> + goto out;
> + moved = 1;
> + }
> +
> +
auth c79684fb subscribe linux-kernel luoji...@gmail.com
auth c79684fb subscribe linux-kernel luoji...@gmail.com
snod->node, snod->len);
+
err = move_node(c, sleb, snod, wbuf);
+ if (err)
+ goto out;
+ moved = 1;
+ }
+
+ if (ubifs_authenticated(c
snod->node, snod->len);
+
err = move_node(c, sleb, snod, wbuf);
+ if (err)
+ goto out;
+ moved = 1;
+ }
+
+ if (ubifs_authenticated(c
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long <lucien@gmail.com>
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long <lucien@gmail.com>
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long <lucien@gmail.com>
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long <lucien@gmail.com>
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long <lucien@gmail.com>
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Xin Long
[ Upstream commit ce402f044e4e432c296f90eaabb8dbe8f3624391 ]
When auth is enabled for cookie-ack chunk, in sctp_inq_pop, sctp
processes auth chunk first, then continues to the next
1 - 100 of 369 matches
Mail list logo
