p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-bluefield · Page n° 77

Vulnérabilité publiée pour linux-bluefield au cours des 30 derniers jours : 0. Dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 3291

  1. CVE-2022-48947

    Élevée · CVSS 7.1EPSS 0,25%Correctif disponible

    Bluetooth: L2CAP: Fix u8 overflow

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,

    • Mettez à jour vers 5.4.0-1058.64
    Publication Mise à jour
  2. CVE-2022-48946

    Élevée · CVSS 7.1EPSS 0,25%Correctif disponible

    udf: Fix preallocation discarding at indirect extent boundary

    In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.

    • Mettez à jour vers 5.4.0-1059.65
    Publication Mise à jour
  3. CVE-2024-50059

    Élevée · CVSS 7.8EPSS 0,23%Correctif disponible

    ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition

    In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  4. CVE-2024-50045

    Élevée · CVSS 7.5EPSS 0,61%Correctif disponible

    netfilter: br_netfilter: fix panic with metadata_dst skb

    In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are ca

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  5. CVE-2024-50040

    Moyenne · CVSS 5.5EPSS 0,26%Correctif disponible

    igb: Do not bring the device up after non-fatal error

    In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  6. CVE-2024-50039

    Élevée · CVSS 7.8EPSS 0,25%Correctif disponible

    net/sched: accept TCA_STAB only for root qdisc

    In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-p

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  7. CVE-2024-50035

    Élevée · CVSS 7.1EPSS 0,27%Correctif disponible

    ppp: fix ppp_async_encode() illegal access

    In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_b

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  8. CVE-2024-50033

    Critique · CVSS 9.8EPSS 0,78%Correctif disponible

    slip: make slhc_remember() more robust against malicious packets

    In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x3

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  9. CVE-2024-50024

    Élevée · CVSS 7.3EPSS 0,28%Correctif disponible

    net: Fix an unsafe loop on the list

    In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  10. CVE-2024-50008

    Moyenne · CVSS 5.5EPSS 0,25%Correctif disponible

    wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()

    In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwi

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  11. CVE-2024-50007

    Élevée · CVSS 7.8EPSS 0,25%Correctif disponible

    ALSA: asihpi: Fix potential OOB array access

    In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  12. CVE-2024-50006

    Moyenne · CVSS 4.7EPSS 0,19%Correctif disponible

    ext4: fix i_data_sem unlock order in ext4_ind_migrate()

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  13. CVE-2024-49997

    Élevée · CVSS 7.5EPSS 1,06%Correctif disponible

    net: ethernet: lantiq_etop: fix memory disclosure

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  14. CVE-2024-49996

    Critique · CVSS 9.4EPSS 0,78%Correctif disponible

    cifs: Fix buffer overflow when parsing NFS reparse points

    In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to pr

    • Mettez à jour vers 5.4.0-1101.108
    Publication Mise à jour
  15. CVE-2024-49985

    Moyenne · CVSS 5.7EPSS 0,2%Correctif disponible

    i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

    In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  16. CVE-2024-49982

    Élevée · CVSS 8.8EPSS 0,38%Correctif disponible

    aoe: fix the potential use-after-free problem in more places

    In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refc

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  17. CVE-2024-49981

    Élevée · CVSS 7.8EPSS 0,19%Correctif disponible

    media: venus: fix use after free bug in venus_remove due to race condition

    In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queue

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour
  18. CVE-2024-49975

    Moyenne · CVSS 5.5EPSS 0,25%Correctif disponible

    uprobes: fix kernel info leak via "[uprobes]" vma

    In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.

    • Mettez à jour vers 5.4.0-1099.106
    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →