A denial of service vulnerability present in ActiveRecord's PostgreSQL adapter <7.0.4.1 and <6.1.7.1. When a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.

**Overview**

Recently, when adding support to Sequel for automatically validating values of integer columns based on the underlying column type, I came across some unfortunate behavior in PostgreSQL. The unfortunate behavior comes from a combination of two features:

*   When using an integer value in an SQL query that is outside the range for a 64-bit signed integer type, PostgreSQL will treat the column type as numeric (since it is too large for bigint).
*   When doing a comparison between an integer or bigint value and a numeric value, PostgreSQL will implicitly cast the integer or bigint value to numeric, then do the comparison.

So if you have an integer or bigint column in your table named id, with a regular index, and you issue an SQL query such as SELECT * FROM table_name WHERE id = 9223372036854775808, PostgreSQL will not use any index on the table, because the index is on the value of the column, not the value of the column after it has been casted to numeric.

**Example of Issue**

Here's an example of the behavior. We first create a table with 1,000,000 rows, then create an index on it:

    CREATE TABLE a AS SELECT * FROM generate_series(1,1000000) AS a(id);
    CREATE INDEX ON a(id);
    

We can then check the query plan when using an integer inside the bigint range:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 9223372036854775807;
                                                       QUERY PLAN
    -----------------------------------------------------------------------------------------------------------------
     Index Only Scan using a_id_idx on a  (cost=0.42..4.44 rows=1 width=4) (actual time=0.088..0.089 rows=0 loops=1)
       Index Cond: (id = '9223372036854775807'::bigint)
       Heap Fetches: 0
     Planning Time: 0.327 ms
     Execution Time: 0.117 ms
    

This is as expected, uses the index, and executes in well under a millisecond.

Next we can check the query plan when using an integer outside the bigint range:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 9223372036854775808;
                                                         QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=4) (actual time=169.630..177.069 rows=0 loops=1)
      Workers Planned: 2
      Workers Launched: 2
      ->  Parallel Seq Scan on a  (cost=0.00..10675.00 rows=2083 width=4) (actual time=158.821..158.821 rows=0 loops=3)
            Filter: ((id)::numeric = '9223372036854775808'::numeric)
            Rows Removed by Filter: 333333
     Planning Time: 0.095 ms
     Execution Time: 177.091 ms
    

This is the unforunate behavior, showing a sequential scan with performance over 1000 times worse.

For large tables, forcing a sequential scan is very negative in terms of performance. If you have an application that will accept a user-supplied integer outside the bigint range, and will use the value directly in an SQL query on a large table, this is a potential denial of service vector.

**Mitigations**

There are a few ways to avoid this issue. One way is using bound variables. Another is raising an exception instead of running the query if the integer is outside the bigint range.

A third way is explicitly casting the value from numeric to integer or bigint depending on the integer value or expected type. You cannot always cast to bigint, as that will break code:

    
    SELECT '[1]'::jsonb - 1;
     ?column?
    ----------
     [1]
    (1 row)
    
    SELECT '[1]'::jsonb - 1::integer;
     ?column?
    ----------
     [1]
    (1 row)
    
    SELECT '[1]'::jsonb - 1::bigint;
    ERROR:  operator does not exist: jsonb - bigint
    LINE 1: SELECT '[1]'::jsonb - 1::bigint;
                                ^
    HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
    

Explicit casting based on the integer value is a fairly pointless mitigation, though, because you have to check the size of the value, and if the value is outside the bigint range, you might as well raise an exception first, instead of sending a query that you know the database return an error for. Explicit casting based on the expected type should be fine.

A fourth way is quoting the value, as if it were a string (e.g. SELECT * FROM t WHERE id = '9223372036854775808'). PostgreSQL treats the single quoted values as the unknown type, which get implicitly casted to the type of whatever it is compared against. If the value provided is outside of the range of that type, PostgreSQL will return an error. However, quoting integers can break code that depends on the implicit type:

    SELECT 1 + 1;
     ?column?
    ----------
            2
    (1 row)
    
    SELECT '1' + '1';
    ERROR:  operator is not unique: unknown + unknown
    LINE 1: SELECT '1' + '1';
                       ^
    HINT:  Could not choose a best candidate operator. You might need to add explicit type casts.
    

Worse, it can silently change the behavior of SQL queries:

    SELECT json_build_array(1);
     json_build_array
    ------------------
     [1]
    (1 row)
    
    SELECT json_build_array('1');
     json_build_array
    ------------------
     ["1"]
    (1 row)
    

For these reasons, I don't think it makes sense to explicitly cast based on the value or quote the values. Unless you are using bound variables, you should either explicitly check the values of integers before using the integers in SQL queries, or explicit cast to the expected type.

A fifth way would be creating an index on the integer column casted to numeric:

    CREATE INDEX ON a((id::numeric));
    

That's more of a workaround than a fix, and should only be used if you access to the database but no ability to fix the underlying code or SQL queries.

**Not a PostgreSQL Bug**

I reached out to the PostgreSQL developers regarding this issue and they informed me this is not a bug. They said this should be handled on the client side, best done using bound variables.

**Are You Affected?**

If you want to know whether you are affected by this issue, ask yourself the following four questions:

*   Am I using PostgreSQL?
*   Am I using a programming language that supports integers outside the bigint range (most dynamically typed programming languages will)?
*   Am I accepting integer values derived from user input, without validating whether they are in the bigint range?
*   Am I using the integer values literally in my queries, without quoting, explicit casting, or using bound variables?

If you answered yes to all four questions, you are probably vulnerable. If your programming language uses fixed sized integer types, you are probably not vulnerable, unless you are using an unsigned 64-bit type for an integer value that you'll be literalizing into an SQL query. If your application or database library is validating the integer values before using them, to make sure they are within the range of a signed 64-bit integer type, then you are probably not vulnerable. If you are quoting the integers, explicitly casting, or using bound variables, you are probably not vulnerable.

**Behavior of Other Numeric Type Comparisons on PostgreSQL**

Because PostgreSQL treats literal numbers with decimal points as numeric values, you can also force a sequential scan by using a number with a decimal point:

    EXPLAIN ANALYZE SELECT id FROM a WHERE id = 1.0;
                                                         QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=4) (actual time=0.239..169.829 rows=1 loops=1)
       Workers Planned: 2
       Workers Launched: 2
       ->  Parallel Seq Scan on a  (cost=0.00..10675.00 rows=2083 width=4) (actual time=98.581..152.694 rows=0 loops=3)
             Filter: ((id)::numeric = 1.0)
             Rows Removed by Filter: 333333
     Planning Time: 0.105 ms
     Execution Time: 169.858 ms
    

When performing a integer = double precision comparison, PostgreSQL will cast the integer to double precision. So this issue also affects queries that use double precision or real values.

When performing a double precision = integer or double precision = numeric comparison, PostgreSQL will cast the integer or numeric to double precision instead of the other way around. So you cannot force a sequential scan for real or double precision columns.

However, you can force a sequential scan for numeric columns, if the value is double precision or real:

    CREATE TABLE ns (id numeric);
    INSERT INTO ns SELECT id FROM a;
    CREATE INDEX ON ns(id);
    EXPLAIN ANALYZE SELECT id FROM ns WHERE id = 1.0::double precision;
                                                          QUERY PLAN
    ----------------------------------------------------------------------------------------------------------------------
     Gather  (cost=1000.00..12175.00 rows=5000 width=6) (actual time=225.169..233.160 rows=0 loops=1)
       Workers Planned: 2
       Workers Launched: 2
       ->  Parallel Seq Scan on ns  (cost=0.00..10675.00 rows=2083 width=6) (actual time=215.148..215.149 rows=0 loops=3)
             Filter: ((id)::double precision = '1'::double precision)
             Rows Removed by Filter: 333333
     Planning Time: 0.125 ms
     Execution Time: 233.183 ms
    

This isn't likely to be an issue in real code, since it can only be hit when you are manually casting the input to double precision. For safety, if you have to cast a floating point number, cast to numeric unless you are sure the underlying type uses double precision. Casting to numeric is safer because it will not cause a sequential scan for either numeric or double precision columns.

Queries similar to those in this section can also be a denial of service vector. If you have an integer column, you should not compare it to a user-provided floating point value. You can run into this issue even when using bound variables, if you are casting the values based on a user-provided type. You should always try to typecast any user-provided input to the appropriate type, you shouldn't trust the type of user input.

The difference between the queries in this section and the integer = numeric query given earlier is that the queries in this section will always result in a sequential scan for the same types in the programming language, regardless of the size of the value. With the integer = numeric query given earlier, a sequential scan can occur for different values of the same type in your programming language, because PostgreSQL implicitly treats the integer values outside the bigint range as numeric. Because the switch from an index scan to a sequential scan occurs for a different value of the same type (from a programming language perspective), I consider that a more serious issue.

**Behavior of Other Databases**

To determine whether PostgreSQL's behavior is reasonable, we can consider how other databases handle the same issue. I tested all 11 SQL databases that Sequel supports. To perform this testing, I used the following Sequel code, which inserts 2\*\*20 (~1,000,000) records, then times queries for values at the boundaries of signed and unsigned 32-bit and 64-bit types:

    DB.create_table(:large_table_test){Integer :id}
    at_exit{DB.drop_table(:large_table_test)}
    ds = DB[:large_table_test]
    ds.insert(1)
    i = 1
    20.times do 
      ds.insert([:id], ds.select{id+i})
      i *= 2
    end
    DB.add_index(:large_table_test, :id)
    puts "#{ds.count} records:"
    
    require 'benchmark'
    [0, 2**31-1, 2**31, 2**32-1, 2**32, 2**63-1, 2**63, 2**64-1, 2**64].each do |i|
      puts "WHERE (id = #{i}): #{Benchmark.measure{ds.first(id: Sequel.lit((i).to_s))}}"
    end
    

Here are the results:

*   PostgreSQL: **Vulnerable**
*   MySQL: Not Vulnerable
*   SQLite: Not Vulnerable
*   Microsoft SQL Server: Not Vulnerable
*   H2: Not Vulnerable
*   HSQLDB: Not Vulnerable
*   Apache Derby: Not Vulnerable
*   Oracle: Not Vulnerable
*   DB2: Not Vulnerable
*   SQLAnywhere: Not Vulnerable
*   Microsoft Access: Not Vulnerable

Only PostgreSQL had a significant difference in performance, showing much worse performance for 2**63, 2**64-1, and 2**64 than for the lower values.

**Potential Changes to PostgreSQL**

The behavior of treating integers outside bigint range as numeric has always been documented by PostgreSQL, so that definitely cannot be considered a bug. I think that behavior is reasonable, because the bigint type cannot support such integers. The only alternative would be raising an error, and that change is impossible due to backwards compatibility.

The actual problematic behavior is when PostgreSQL does an integer = numeric or integer = double precision comparison, it casts the integer to numeric or double precision as the first step. This the behavior that results the sequential scan, since it prevents the use of an index on the column. I think it would be better to first check if the numeric or double precision value can be represented as a value of the integer type it is compared against. If the numeric or double precision value is outside the range of that integer type or has a fractional value, then you could treat the equality comparison as false (modulo NULL handling). However, I have no knowledge of PostgreSQL internals, and therefore no idea whether such an approach is feasible.

**Changes to Sequel**

Applications using Sequel could be vulnerable to this issue, if they were not checking the sizes of the integer values, since it used large integer values directly in queries. The first change I made was to have Sequel's PostgreSQL adapter raise an exception if attempting to literalize an integer outside the bigint range. For users that really want the previous behavior, I added an extension that allowed them to select the old behavior, or to quote the large integer values.

This issue taught me a valuable lesson. For many years, I've thought using values directly in SQL queries is fine, as long as you correctly escape them. Turns out that user provided integers are not safe on PostgreSQL. If I was using bound variables, I wouldn't have needed to worry about this issue. So to prevent this type of issue in the future, I ressurected Sequel's pg_auto_parameterize extension, which uses bound variables automatically. This extension was originally added in Sequel 3.34.0, and then removed in Sequel 4.0.0 because it had many corner cases. I was able to fix almost all of the corner cases, and for the last two weeks have been running all of my applications using the pg_auto_parameterize extension. I recommend that all Sequel users using the PostgreSQL adapter try out the pg_auto_parameterize extension and see if it works for them. As mentioned above, automatically using bound variables does not prevent the issue if you are supporting arbitrary types submitted by users (e.g. users submitting float values for integer columns), so you should make sure you are validating that submitted types are expected (and/or converting submitted types to expected types).

**Updates (last updated: 2022-11-04)**

This post resulted in a small but informative discussion on Lobsters. A few things I learned from the replies:

*   This issue affected Reddit years ago, and they added validations on integer values before queries to work around it.
*   Using bound variables does not necessarily solve this issue if the datatype specified for the bound variable is also one that will cause a sequential scan. This is the equivalent of an explicit cast, and an explicit cast to the wrong type can also cause a sequential scan. This can even happen by default when using JDBC if using the setObject method instead of the setLong method for integers.
*   My point in the section about other numeric type comparisons and how they differ from the main integer = numeric comparison is true for programming languages like Ruby, which have separate integer and decimal/floating point types. However, it's probably not true for programming languages that only have a single numeric type that works for both integers and decimal/floating point values, such as JavaScript and Lua before 5.3. So if you are using a programming language that only has a single numeric type for integers and decimal/floating point values, you need to be very careful in all of your input handling, ensuring the only integer values are used for comparison to PostgreSQL integer columns, or using explicit casts to the expected integer type for all queries involving comparisons to integer columns.

This post was featured in Episode 42 of the 5mins of Postgres video series.

**Other Software Affected (last updated: 2023-01-17)**

I found that this issue affected other libraries besides Sequel. Here is a list of other libraries that were or are affected:

*   ActiveRecord is a database library for Ruby, part of Ruby on Rails. I reported this issue privately to the Rails security list. Rails fixed this issue in Rails 7.0.4.1 and 6.1.7.1.
*   Sequelize is a database library for JavaScript/TypeScript. I reported this issue privately to the maintainers, and it appears they fixed it during a very large refactoring commit.
*   SQLObject is a database library for Python. I submitted a GitHub Issue discussing this topic, but the maintainers do not think it is a security issue in SQLObject. They are unsure if it should be fixed in SQLObject itself, or in applications using SQLObject.

I think it is highly likely that other database libraries are affected, but these are the libraries I found vulnerable in the brief time I spent testing other libraries.

CVE-2022-44566: Forcing Sequential Scans on PostgreSQL Using Large Integers (2022-11-01)

A Stack-based overflow vulnerability in IpcRxEmbmsSessionList in SECRIL prior to Android S(12) allows attacker to cause memory corruptions.

This Cookie Policy describes the different types of cookies that may be used in connection with Samsung Mobile Security website which is owned and controlled by Samsung Electronics Co., Ltd (“Samsung Electronics”). This Cookie Policy also describes how you can manage cookies.

It’s important that you check back often for updates to the Policy as we may change it from time to time to reflect changes to our use of cookies. Please check the date at the top of this page to see when this Policy was last revised. Any changes to this Policy will become effective when we make the revised Policy available on our website.

Samsung Electronics has offices across Europe, so we can ensure that your request or query will be handled by the data protection team based in your region. If you have any questions, the easiest way to contact us is through our Privacy Support Page at https://www.samsung.com/request-desk.

You can also contact us at:

European Data Protection Officer  
Samsung Electronics (UK) Limited  
Samsung House, 2000 Hillswood Drive, Chertsey, Surrey KT16 0RS

**Cookies**

Cookies are small files that store information on your computer, TV, mobile phone, or other device. They enable the entity that put the cookie on your device to recognize you across different websites, services, devices, and/or browsing sessions.

We use the following types of cookies on this website:

**Essential Cookies**: enable you to receive the services you request via our website. Without these cookies, services that you have asked for cannot be provided. For example, these enable to identify users and provide proper service for each user. These cookies are automatically enabled and cannot be turned off because they are essential to enable you to browse our website. Without these cookies this Samsung Mobile Security website could not be provided.

Cookie

Domain

Purpose

JSESSIONID

security.samsungmobile.com

to keep login session

lastActivityTime

security.samsungmobile.com

to save the user's last activity time to automatically logout after 30 minutes of inactivity

**Managing Cookies and Other Technologies**

You can also update your browser settings at any time, if you want to remove or block cookies from your device (consult your browser's "help" menu to learn how to remove or block cookies). Samsung Electronics is not responsible for your browser settings. You can find good and simple instructions on how to manage cookies on the different types of web browsers at http://www.allaboutcookies.org.

CVE-2023-21451: Samsung Mobile Security

Missing Authorization vulnerability in One Hand Operation + prior to version 6.1.21 allows multi-users to access owner&#39;s widget without authorization via gesture setting.

CVE-2023-21450: Samsung Mobile Security

Improper access control vulnerability in WindowManagerService prior to SMR Feb-2023 Release 1 allows attackers to take a screen capture.

CVE-2023-21440: Samsung Mobile Security

An improper implementation logic in Secure Folder prior to SMR Jan-2023 Release 1 allows the Secure Folder container remain unlocked under certain condition.

CVE-2023-21419: Samsung Mobile Security

Improper input validation vulnerability in Galaxy Store prior to version 4.5.49.8 allows local attackers to execute JavaScript by launching a web page.

CVE-2023-21434: Samsung Mobile Security

Red Hat Security Advisory 2023-0691-01 - Open vSwitch provides standard network bridging functions and support for the OpenFlow protocol for remote per-flow control of traffic. Issues addressed include an out of bounds read vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: openvswitch2.17 security, bug fix and enhancement update  
Advisory ID:       RHSA-2023:0691-01  
Product:           Fast Datapath  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0691  
Issue date:        2023-02-09  
CVE Names:         CVE-2022-4337 CVE-2022-4338   
=====================================================================

1. Summary:

An update for openvswitch2.17 is now available for Fast Datapath for Red  
Hat Enterprise Linux 9.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Fast Datapath for Red Hat Enterprise Linux 9 - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Open vSwitch provides standard network bridging functions and support for  
the OpenFlow protocol for remote per-flow control of traffic.

Security Fix(es):

* openvswitch: Out-of-Bounds Read in Organization Specific TLV  
(CVE-2022-4337)  
* openvswitch: Integer Underflow in Organization Specific TLV  
(CVE-2022-4338)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2155378 - CVE-2022-4337 openvswitch: Out-of-Bounds Read in Organization Specific TLV  
2155381 - CVE-2022-4338 openvswitch: Integer Underflow in Organization Specific TLV  
2159419 - [ovs2.11][RHEL7.7] PF/VF Port statistics get over-run in OVS offload datapath  
2162035 - [23.A RHEL-9] Fast Datapath Release

6. Package List:

Fast Datapath for Red Hat Enterprise Linux 9:

Source:  
openvswitch2.17-2.17.0-62.el9fdp.src.rpm

aarch64:  
openvswitch2.17-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.aarch64.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.aarch64.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.aarch64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.aarch64.rpm

noarch:  
openvswitch2.17-test-2.17.0-62.el9fdp.noarch.rpm

ppc64le:  
openvswitch2.17-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.ppc64le.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.ppc64le.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.ppc64le.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.ppc64le.rpm

s390x:  
openvswitch2.17-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.s390x.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.s390x.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.s390x.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.s390x.rpm

x86_64:  
openvswitch2.17-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-debuginfo-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-debugsource-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-devel-2.17.0-62.el9fdp.x86_64.rpm  
openvswitch2.17-ipsec-2.17.0-62.el9fdp.x86_64.rpm  
python3-openvswitch2.17-2.17.0-62.el9fdp.x86_64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-62.el9fdp.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-4337  
https://access.redhat.com/security/cve/CVE-2022-4338  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY+RnytzjgjWX9erEAQh83hAAn7wZtp4GczoBt9pm1Cbl8ug0NFzax2Ve  
D1VedORejT43jl84X2tHGsMx95heFU0eCmIMD88Szqj9Vx3Yi3IZPX1htRNVb2mC  
4u27n+uAaIGFVkNcx1aWfKO2qitYmCCSsg2zQenJqhe+Pt4gUmvRy2R7feiyW91Q  
u7xo3kHyaOof9J+87WWq+xxmEXp6gAOl7/pzClew38cq/f7bUmHiMZE4o+nlM6rJ  
jhCvDQSr4PVaHBqiHsh1dH4npuXqkBzlqi0uG2qgU4sAhfEMhmG0eI52q7TzUm4w  
ASCz3c6aOYLQq4e0CXrB4+tHf2tN1SJCA4YBjhvFnPUbidxfdAOqvImj3dAJAvvc  
Oc93W74Zb1zIxHBkRWeVNzOEKQT8WOHrAzMbWEYObndTvKcvv6xn582dIbwgT4oy  
Z62tl6VHDTbemWkN+BcTAIllIqyamhBNv9VgzUpIeIk9TGj5Mh7qDn2dL9pJv//o  
n4D9FUfal2elVLjFqlJ23m0nU9S6EYNGv8FisfUA32sFu2HxRRmDoC7AoBPxUzQj  
U5o8RIEPVnwWfjvuKC9LymDKRU4AQV11GIEGq6zEvZYP2A8j/oDpfEmTmg5NhUeI  
Z8QlezHTOyMfGjsFfkz+8MzKuwabA7phwvYk/MRRE81Pr7cpDebKHy37NfAhaEp9  
w9uYO6IHLig=  
=B0kT  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-0691-01

Red Hat Security Advisory 2023-0688-01 - Open vSwitch provides standard network bridging functions and support for the OpenFlow protocol for remote per-flow control of traffic. Issues addressed include an out of bounds read vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: openvswitch2.17 security, bug fix and enhancement update  
Advisory ID:       RHSA-2023:0688-01  
Product:           Fast Datapath  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0688  
Issue date:        2023-02-09  
CVE Names:         CVE-2022-4337 CVE-2022-4338   
=====================================================================

1. Summary:

An update for openvswitch2.17 is now available for Fast Datapath for Red  
Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Fast Datapath for Red Hat Enterprise Linux 8 - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Open vSwitch provides standard network bridging functions and support for  
the OpenFlow protocol for remote per-flow control of traffic.

Security Fix(es):

* openvswitch: Out-of-Bounds Read in Organization Specific TLV  
(CVE-2022-4337)  
* openvswitch: Integer Underflow in Organization Specific TLV  
(CVE-2022-4338)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2155378 - CVE-2022-4337 openvswitch: Out-of-Bounds Read in Organization Specific TLV  
2155381 - CVE-2022-4338 openvswitch: Integer Underflow in Organization Specific TLV  
2162034 - [23.A RHEL-8] Fast Datapath Release

6. Package List:

Fast Datapath for Red Hat Enterprise Linux 8:

Source:  
openvswitch2.17-2.17.0-71.el8fdp.src.rpm

aarch64:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.aarch64.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.aarch64.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.aarch64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.aarch64.rpm

noarch:  
openvswitch2.17-test-2.17.0-71.el8fdp.noarch.rpm

ppc64le:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.ppc64le.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.ppc64le.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.ppc64le.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.ppc64le.rpm

s390x:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.s390x.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.s390x.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.s390x.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.s390x.rpm

x86_64:  
network-scripts-openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-debuginfo-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-debugsource-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-devel-2.17.0-71.el8fdp.x86_64.rpm  
openvswitch2.17-ipsec-2.17.0-71.el8fdp.x86_64.rpm  
python3-openvswitch2.17-2.17.0-71.el8fdp.x86_64.rpm  
python3-openvswitch2.17-debuginfo-2.17.0-71.el8fdp.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-4337  
https://access.redhat.com/security/cve/CVE-2022-4338  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY+RnxNzjgjWX9erEAQiAng/8CEF0s+9tyHZJ5vvhbA4EMhTBY30BvlWf  
WPyybqxk2tucXuk4ARfruStnf/AZpL8xtf9aznCOhP4vacrpWYp7PJausIRfLKwG  
Jk1xsOJs3imyKSMkJR9ilJBvuyG6GFD9e/RR/2z5H1vpcw1ldL9MpizDyVLy0I3F  
XYjgMIHJDC66PwJRua4ABeiIrX2P8+tCm3cynXxrA/08DvVsQ/HZMnO5XMZh6+uw  
QXubvp6ThkNJBLi5fENErJWAlpu31c/sI6njP7VZdInRX+mDh99aDFFvAGZ4RetQ  
DslipMvHpe7niXEJ9EEXirAZkGOHhNQmh5e3wXYjc4Fn1lq+hLDB2friB0rNdBlR  
e4BG3m3wK9TebgvpLkK7mt3jdn8zlxAtY33Wg2SYSHLwpFj0kxQ0tZAKQTTpwc9l  
Ek/yfFubEGfZoYIhqCBFOEnEb635SVXQYFL2QQw4JGZf46xEewBxLxftp/SZ4H7D  
eLQXmrBHflEALaqnazOPObNNw2jB7gQmm5svAatZd1fy1vcFVIqB7hdy701SpWBm  
jzlvazTq59t3UmlUPs9OhkIOR//BaUuuSLqNm3xPGxE2hHOsC/yURdYBcfFRRBcf  
zqWOHIRNysHcyzBMtixtnbB9S4uf5EKo9RGf2TLGRW1ZdFYN2TsA7ryklWo/9RRD  
QliC+OVLpHo=  
=mmIf  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-0688-01

Red Hat Security Advisory 2023-0692-01 - OpenShift API for Data Protection enables you to back up and restore application resources, persistent volume data, and internal container images to external backup storage. OADP enables both file system-based and snapshot-based backups for persistent volumes.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: OpenShift API for Data Protection (OADP) 1.0.7 security and bug fix update  
Advisory ID:       RHSA-2023:0692-01  
Product:           OpenShift API for Data Protection  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0692  
Issue date:        2023-02-09  
CVE Names:         CVE-2022-32149 CVE-2022-41717   
=====================================================================

1. Summary:

OpenShift API for Data Protection (OADP) 1.0.7 is now available.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

OpenShift API for Data Protection (OADP) enables you to back up and restore  
application resources, persistent volume data, and internal container  
images to external backup storage. OADP enables both file system-based and  
snapshot-based backups for persistent volumes.

Security Fix(es) from Bugzilla:

* golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time  
to parse complex tags (CVE-2022-32149)

* golang: net/http: An attacker can cause excessive memory growth in a Go  
server accepting HTTP/2 requests (CVE-2022-41717)

For more details about the security issue(s), including the impact, a CVSS  
score, and other related information, refer to the CVE page(s) listed in  
the References section.

3. Solution:

Before applying this update, make sure all previously released errata  
relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258

4. Bugs fixed (https://bugzilla.redhat.com/):

2134010 - CVE-2022-32149 golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time to parse complex tags  
2161274 - CVE-2022-41717 golang: net/http: An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests

5. JIRA issues fixed (https://issues.jboss.org/):

MIG-1050 - Keep the annotation "pv.kubernetes.io/provisioned-by"  
OADP-1180 - [OADP] Backup get stuck at Inprogress status, as velero pod is getting restarted due to fatal error

6. References:

https://access.redhat.com/security/cve/CVE-2022-32149  
https://access.redhat.com/security/cve/CVE-2022-41717  
https://access.redhat.com/security/updates/classification/#moderate

7. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY+RnwdzjgjWX9erEAQgQwg/6Aw0TWgJ8Tp1HVLBVWMo9iaPjGS1/ZufG  
YPQkgk4wwGwbtSVytQxSxABF80wCJUe9wI4OBjrFlqFLXtzH9X53H2MA1fBCbJ17  
692H/GVwLpY8fiw5sNBFEnfN3yuNvzz4K3onc0Ggk/Xr9JjFbxiYkd+vRygdQPKc  
AteQ7Bc3+0Qdzs9UX4IrJLSkC69kmBdfiA1/PhPpnzVO269Jm+9g7EOAyqciXJ19  
z9iPN8D89254KxtCnvnbDfByPt04u29yRFdFQYBlpgJzcE7hY5wW/Cwc81JOko+Q  
RsF2MR2+Pz0jCr8h/2xnyayDp0mjdkcB+DtJgPgBa1uIbb/cz109g+M/2i2flMfM  
rTDrRxYEndZ8JDMmeSCn1Gncoo29vE4Y6uiylLRwv+uj3WpmH6J3QrQ/4sEpusLO  
OHs8cvczfIcxiQXNNp+lMR1HPd1CWCiK0sRazJ7JnzK12PHOZA6v4lmm6RAtBxdY  
CGvVlgQG8tT9X70GJ6bbM0g9ozAezqTY4MLODBD+vbR0Qbf/gQWRBwMAr4SZErSH  
P1fEYDAMOpwwm7eWqGC7NYSMr1oxSJSz8Ad1Ep84/pYB9hEvHZMCpRFNOoLEUXjo  
OAsurqZnG5fYV8p+2yyOvlLSwdoq57b5Jz0ywjIbZn4bCB91OVDyqeR/X7yB+8ja  
+VdlUZO5m2s=  
=+hgQ  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-0692-01

Red Hat Security Advisory 2023-0693-01 - The Migration Toolkit for Containers enables you to migrate Kubernetes resources, persistent volume data, and internal container images between OpenShift Container Platform clusters, using the MTC web console or the Kubernetes API. Issues addressed include a denial of service vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: Migration Toolkit for Containers (MTC) 1.7.7 security and bug fix update  
Advisory ID:       RHSA-2023:0693-01  
Product:           Red Hat Migration Toolkit  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0693  
Issue date:        2023-02-09  
CVE Names:         CVE-2021-4235 CVE-2021-43138 CVE-2021-46848   
                   CVE-2022-2056 CVE-2022-2057 CVE-2022-2058   
                   CVE-2022-2519 CVE-2022-2520 CVE-2022-2521   
                   CVE-2022-2867 CVE-2022-2868 CVE-2022-2869   
                   CVE-2022-2879 CVE-2022-2880 CVE-2022-2953   
                   CVE-2022-2995 CVE-2022-3162 CVE-2022-3172   
                   CVE-2022-3259 CVE-2022-3466 CVE-2022-3821   
                   CVE-2022-4883 CVE-2022-27664 CVE-2022-30631   
                   CVE-2022-32148 CVE-2022-32149 CVE-2022-32189   
                   CVE-2022-32190 CVE-2022-35737 CVE-2022-40303   
                   CVE-2022-40304 CVE-2022-41715 CVE-2022-41717   
                   CVE-2022-42010 CVE-2022-42011 CVE-2022-42012   
                   CVE-2022-43680 CVE-2022-44617 CVE-2022-46285   
=====================================================================

1. Summary:

The Migration Toolkit for Containers (MTC) 1.7.7 is now available.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

The Migration Toolkit for Containers (MTC) enables you to migrate  
Kubernetes resources, persistent volume data, and internal container images  
between OpenShift Container Platform clusters, using the MTC web console or  
the Kubernetes API.

Security Fix(es) from Bugzilla:

* async: Prototype Pollution in async (CVE-2021-43138)

* golang: archive/tar: unbounded memory consumption when reading headers  
(CVE-2022-2879)

* golang: net/http/httputil: ReverseProxy should not forward unparseable  
query parameters (CVE-2022-2880)

* golang: net/http: handle server errors after sending GOAWAY  
(CVE-2022-27664)

* golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time  
to parse complex tags (CVE-2022-32149)

* golang: net/url: JoinPath does not strip relative path components in all  
circumstances (CVE-2022-32190)

* golang: regexp/syntax: limit memory used by parsing regexps  
(CVE-2022-41715)

* golang: net/http: An attacker can cause excessive memory growth in a Go  
server accepting HTTP/2 requests (CVE-2022-41717)

* golang: math/big: decoding big.Float and big.Rat types can panic if the  
encoded message is too short, potentially allowing a denial of service  
(CVE-2022-32189)

For more details about the security issue(s), including the impact, a CVSS  
score, and other related information, refer to the CVE page(s) listed in  
the References section.

3. Solution:

For details on how to install and use MTC, refer to:

https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

4. Bugs fixed (https://bugzilla.redhat.com/):

2113814 - CVE-2022-32189 golang: math/big: decoding big.Float and big.Rat types can panic if the encoded message is too short, potentially allowing a denial of service  
2124668 - CVE-2022-32190 golang: net/url: JoinPath does not strip relative path components in all circumstances  
2124669 - CVE-2022-27664 golang: net/http: handle server errors after sending GOAWAY  
2126276 - CVE-2021-43138 async: Prototype Pollution in async  
2132867 - CVE-2022-2879 golang: archive/tar: unbounded memory consumption when reading headers  
2132868 - CVE-2022-2880 golang: net/http/httputil: ReverseProxy should not forward unparseable query parameters  
2132872 - CVE-2022-41715 golang: regexp/syntax: limit memory used by parsing regexps  
2134010 - CVE-2022-32149 golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time to parse complex tags  
2160662 - Velero pod crashing leading to migrations being stuck during Backup Phase  
2161274 - CVE-2022-41717 golang: net/http: An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests

5. JIRA issues fixed (https://issues.jboss.org/):

MIG-1275 - Update base image for hook-runner so kubernetes.core 2.3.2 or newer is present  
MIG-1281 - Allow DVM to be configured with alternative network strategies, more than an openshift route.

6. References:

https://access.redhat.com/security/cve/CVE-2021-4235  
https://access.redhat.com/security/cve/CVE-2021-43138  
https://access.redhat.com/security/cve/CVE-2021-46848  
https://access.redhat.com/security/cve/CVE-2022-2056  
https://access.redhat.com/security/cve/CVE-2022-2057  
https://access.redhat.com/security/cve/CVE-2022-2058  
https://access.redhat.com/security/cve/CVE-2022-2519  
https://access.redhat.com/security/cve/CVE-2022-2520  
https://access.redhat.com/security/cve/CVE-2022-2521  
https://access.redhat.com/security/cve/CVE-2022-2867  
https://access.redhat.com/security/cve/CVE-2022-2868  
https://access.redhat.com/security/cve/CVE-2022-2869  
https://access.redhat.com/security/cve/CVE-2022-2879  
https://access.redhat.com/security/cve/CVE-2022-2880  
https://access.redhat.com/security/cve/CVE-2022-2953  
https://access.redhat.com/security/cve/CVE-2022-2995  
https://access.redhat.com/security/cve/CVE-2022-3162  
https://access.redhat.com/security/cve/CVE-2022-3172  
https://access.redhat.com/security/cve/CVE-2022-3259  
https://access.redhat.com/security/cve/CVE-2022-3466  
https://access.redhat.com/security/cve/CVE-2022-3821  
https://access.redhat.com/security/cve/CVE-2022-4883  
https://access.redhat.com/security/cve/CVE-2022-27664  
https://access.redhat.com/security/cve/CVE-2022-30631  
https://access.redhat.com/security/cve/CVE-2022-32148  
https://access.redhat.com/security/cve/CVE-2022-32149  
https://access.redhat.com/security/cve/CVE-2022-32189  
https://access.redhat.com/security/cve/CVE-2022-32190  
https://access.redhat.com/security/cve/CVE-2022-35737  
https://access.redhat.com/security/cve/CVE-2022-40303  
https://access.redhat.com/security/cve/CVE-2022-40304  
https://access.redhat.com/security/cve/CVE-2022-41715  
https://access.redhat.com/security/cve/CVE-2022-41717  
https://access.redhat.com/security/cve/CVE-2022-42010  
https://access.redhat.com/security/cve/CVE-2022-42011  
https://access.redhat.com/security/cve/CVE-2022-42012  
https://access.redhat.com/security/cve/CVE-2022-43680  
https://access.redhat.com/security/cve/CVE-2022-44617  
https://access.redhat.com/security/cve/CVE-2022-46285  
https://access.redhat.com/security/updates/classification/#moderate

7. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY+RnvtzjgjWX9erEAQj1Uw//Sajfr2eFvjS/4S4vFPjwT4h2vmhZx41v  
khxvUYsIiISMIdqGFyeHwGjJIVZvxLeNJFRgFwg7V/x3pK3cFf7mgFLLIFa+jZOy  
emzSTft3XWAgdAVw8PkrohPTsg49jJHklXBrekoH1HqKUQVbZxpKBjo5iGHbk+K3  
cpUF7ZJoPUa9bRmqE2DIOyQQyKmqivCh61wDQTZjR6S2xOeo0Y666pVl3cOcHpcp  
TVGsnO+o3qvqO7PezE6L1znbifO0jL6dsWFHysAKjYl0MR0hFjeloJVRq4QME49r  
qeDGGITJXfIAQzbo2CzyaP5Ifmre0O1VIAX5QyE3xhzgdn1JUeDBi3kOH1RLGXvq  
oYlkvVhV3xPBH9YK1hmTZalvy79tf9zi24sdk1/U+W/mZz/ZIKqPi+EyB3zio6Tm  
buYmultPogNVUWdRGuXxCCr2Alfw400dfmAFXWQ7JWX6XrxCwqz4YsfpZpslFMjT  
hYIH+jzVDbA3iL6nOJ3U0JnGo68KlcsnBfbGVkUWrf55O5bJp2N1Yf7KHZTcYonx  
QnQID1Xhwjye1pjV7/dCUjBjnXDcVcbfnxExK7AFHih8DBZc9DN3JP/cM1mjK6ab  
9hpMRo0NyfP1DNkpCTOFRmxmeiSvZZlxs1STin6XAbIKnIZdFGMWm7cDQgphXIVt  
Q40G6CG91Uo=  
=8Igd  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#js