1114 lines
139 KiB
JSON
1114 lines
139 KiB
JSON
{
|
|
"Definition": [
|
|
{
|
|
"ID": "oval:org.altlinux.errata:def:202414268",
|
|
"Version": "oval:org.altlinux.errata:def:202414268",
|
|
"Class": "patch",
|
|
"Metadata": {
|
|
"Title": "ALT-PU-2024-14268: package `kernel-image-un-def` update to version 6.1.113-alt1",
|
|
"AffectedList": [
|
|
{
|
|
"Family": "unix",
|
|
"Platforms": [
|
|
"ALT Linux branch p10"
|
|
],
|
|
"Products": [
|
|
"ALT Server",
|
|
"ALT Virtualization Server",
|
|
"ALT Workstation",
|
|
"ALT Workstation K",
|
|
"ALT Education",
|
|
"Simply Linux",
|
|
"Starterkit"
|
|
]
|
|
}
|
|
],
|
|
"References": [
|
|
{
|
|
"RefID": "ALT-PU-2024-14268",
|
|
"RefURL": "https://errata.altlinux.org/ALT-PU-2024-14268",
|
|
"Source": "ALTPU"
|
|
},
|
|
{
|
|
"RefID": "CVE-2023-52917",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47678",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47678",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47679",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47682",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47682",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47683",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47683",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47684",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47685",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47686",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47686",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47690",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47690",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47692",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47693",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47695",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47696",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47697",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47698",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47699",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47699",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47701",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47705",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47705",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47706",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47706",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47707",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47707",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47709",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47710",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47712",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47712",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47713",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47713",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47718",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47718",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47720",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47723",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47727",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47727",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47728",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47728",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47730",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47730",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47731",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47731",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47734",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47734",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47735",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47737",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47738",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47738",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47739",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47739",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47742",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47743",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47743",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47747",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47748",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47748",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47749",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47750",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47750",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47751",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47751",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47756",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47756",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-47757",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49850",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49850",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49851",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49851",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49852",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49852",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49853",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49853",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49854",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49854",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49855",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49856",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49856",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49858",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49858",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49859",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49860",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49863",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49863",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49871",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49871",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49875",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49877",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49879",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49879",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49896",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49896",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49905",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49905",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49907",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49907",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49912",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49912",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-49913",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-49913",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50033",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50035",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50041",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50041",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50044",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50044",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50045",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50046",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50048",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50048",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50049",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50059",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50059",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-50062",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062",
|
|
"Source": "CVE"
|
|
}
|
|
],
|
|
"Description": "This update upgrades kernel-image-un-def to version 6.1.113-alt1. \nSecurity Fix(es):\n\n * CVE-2023-52917: In the Linux kernel, the following vulnerability has been resolved:\n\nntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()\n\nThe debugfs_create_dir() function returns error pointers.\nIt never returns NULL. So use IS_ERR() to check it.\n\n * CVE-2024-47678: In the Linux kernel, the following vulnerability has been resolved:\n\nicmp: change the order of rate limits\n\nICMP messages are ratelimited :\n\nAfter the blamed commits, the two rate limiters are applied in this order:\n\n1) host wide ratelimit (icmp_global_allow())\n\n2) Per destination ratelimit (inetpeer based)\n\nIn order to avoid side-channels attacks, we need to apply\nthe per destination check first.\n\nThis patch makes the following change :\n\n1) icmp_global_allow() checks if the host wide limit is reached.\n But credits are not yet consumed. This is deferred to 3)\n\n2) The per destination limit is checked/updated.\n This might add a new node in inetpeer tree.\n\n3) icmp_global_consume() consumes tokens if prior operations succeeded.\n\nThis means that host wide ratelimit is still effective\nin keeping inetpeer tree small even under DDOS.\n\nAs a bonus, I removed icmp_global.lock as the fast path\ncan use a lock-free operation.\n\n * CVE-2024-47679: In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: fix race between evice_inodes() and find_inode()\u0026iput()\n\nHi, all\n\nRecently I noticed a bug[1] in btrfs, after digged it into\nand I believe it'a race in vfs.\n\nLet's assume there's a inode (ie ino 261) with i_count 1 is\ncalled by iput(), and there's a concurrent thread calling\ngeneric_shutdown_super().\n\ncpu0: cpu1:\niput() // i_count is 1\n -\u003espin_lock(inode)\n -\u003edec i_count to 0\n -\u003eiput_final() generic_shutdown_super()\n -\u003e__inode_add_lru() -\u003eevict_inodes()\n // cause some reason[2] -\u003eif (atomic_read(inode-\u003ei_count)) continue;\n // return before // inode 261 passed the above check\n // list_lru_add_obj() // and then schedule out\n -\u003espin_unlock()\n// note here: the inode 261\n// was still at sb list and hash list,\n// and I_FREEING|I_WILL_FREE was not been set\n\nbtrfs_iget()\n // after some function calls\n -\u003efind_inode()\n // found the above inode 261\n -\u003espin_lock(inode)\n // check I_FREEING|I_WILL_FREE\n // and passed\n -\u003e__iget()\n -\u003espin_unlock(inode) // schedule back\n -\u003espin_lock(inode)\n // check (I_NEW|I_FREEING|I_WILL_FREE) flags,\n // passed and set I_FREEING\niput() -\u003espin_unlock(inode)\n -\u003espin_lock(inode)\t\t\t -\u003eevict()\n // dec i_count to 0\n -\u003eiput_final()\n -\u003espin_unlock()\n -\u003eevict()\n\nNow, we have two threads simultaneously evicting\nthe same inode, which may trigger the BUG(inode-\u003ei_state \u0026 I_CLEAR)\nstatement both within clear_inode() and iput().\n\nTo fix the bug, recheck the inode-\u003ei_count after holding i_lock.\nBecause in the most scenarios, the first check is valid, and\nthe overhead of spin_lock() can be reduced.\n\nIf there is any misunderstanding, please let me know, thanks.\n\n[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/\n[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()\nreturn false when I reproduced the bug.\n\n * CVE-2024-47682: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sd: Fix off-by-one error in sd_read_block_characteristics()\n\nFf the device returns page 0xb1 with length 8 (happens with qemu v2.x, for\nexample), sd_read_block_characteristics() may attempt an out-of-bounds\nmemory access when accessing the zoned field at offset 8.\n\n * CVE-2024-47683: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Skip Recompute DSC Params if no Stream on Link\n\n[why]\nEncounter NULL pointer dereference uner mst + dsc setup.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2\n Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022\n RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]\n Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 \u003c48\u003e 8\u003e\n RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293\n RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224\n RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280\n RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850\n R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000\n R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224\n FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0\n Call Trace:\n\u003cTASK\u003e\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? plist_add+0xbe/0x100\n ? exc_page_fault+0x7c/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n drm_atomic_check_only+0x5c5/0xa40\n drm_mode_atomic_ioctl+0x76e/0xbc0\n\n[how]\ndsc recompute should be skipped if no mode change detected on the new\nrequest. If detected, keep checking whether the stream is already on\ncurrent state or not.\n\n * CVE-2024-47684: In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: check skb is non-NULL in tcp_rto_delta_us()\n\nWe have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic\nkernel that are running ceph and recently hit a null ptr dereference in\ntcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also\nsaw it getting hit from the RACK case as well. Here are examples of the oops\nmessages we saw in each of those cases:\n\nJul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020\nJul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode\nJul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page\nJul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0\nJul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI\nJul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu\nJul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023\nJul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u003c48\u003e 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3\nJul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246\nJul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000\nJul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60\nJul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8\nJul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900\nJul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30\nJul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000\nJul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nJul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0\nJul 26 15:05:02 rx [11061395.913822] PKRU: 55555554\nJul 26 15:05:02 rx [11061395.916786] Call Trace:\nJul 26 15:05:02 rx [11061395.919488]\nJul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f\nJul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9\nJul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380\nJul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0\nJul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50\nJul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0\nJul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20\nJul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450\nJul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140\nJul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90\nJul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0\nJul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40\nJul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220\nJul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240\nJul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0\nJul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240\nJul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130\nJul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280\nJul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10\nJul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30\nJul 26 15:05:02 rx [11061396.017718] ? lapic_next_even\n---truncated---\n\n * CVE-2024-47685: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()\n\nsyzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending\ngarbage on the four reserved tcp bits (th-\u003eres1)\n\nUse skb_put_zero() to clear the whole TCP header,\nas done in nf_reject_ip_tcphdr_put()\n\nBUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255\n nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255\n nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344\n nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48\n expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288\n nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n NF_HOOK include/linux/netfilter.h:312 [inline]\n ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5661 [inline]\n __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775\n process_backlog+0x4ad/0xa50 net/core/dev.c:6108\n __napi_poll+0xe7/0x980 net/core/dev.c:6772\n napi_poll net/core/dev.c:6841 [inline]\n net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963\n handle_softirqs+0x1ce/0x800 kernel/softirq.c:554\n __do_softirq+0x14/0x1a kernel/softirq.c:588\n do_softirq+0x9a/0x100 kernel/softirq.c:455\n __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]\n __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450\n dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141\n __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]\n ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247\n dst_output include/net/dst.h:450 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366\n inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135\n __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466\n tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]\n tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143\n tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333\n __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679\n inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750\n __sys_connect_file net/socket.c:2061 [inline]\n __sys_connect+0x606/0x690 net/socket.c:2078\n __do_sys_connect net/socket.c:2088 [inline]\n __se_sys_connect net/socket.c:2085 [inline]\n __x64_sys_connect+0x91/0xe0 net/socket.c:2085\n x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was stored to memory at:\n nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249\n nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344\n nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48\n expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288\n nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n NF_HOOK include/linux/netfilter.h:312 [inline]\n ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core\n---truncated---\n\n * CVE-2024-47686: In the Linux kernel, the following vulnerability has been resolved:\n\nep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()\n\nThe psc-\u003ediv[] array has psc-\u003enum_div elements. These values come from\nwhen we call clk_hw_register_div(). It's adc_divisors and\nARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be \u003e=\ninstead of \u003e to prevent an out of bounds read.\n\n * CVE-2024-47690: In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: get rid of online repaire on corrupted directory\n\nsyzbot reports a f2fs bug as below:\n\nkernel BUG at fs/f2fs/inode.c:896!\nRIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896\nCall Trace:\n evict+0x532/0x950 fs/inode.c:704\n dispose_list fs/inode.c:747 [inline]\n evict_inodes+0x5f9/0x690 fs/inode.c:797\n generic_shutdown_super+0x9d/0x2d0 fs/super.c:627\n kill_block_super+0x44/0x90 fs/super.c:1696\n kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898\n deactivate_locked_super+0xc4/0x130 fs/super.c:473\n cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n ptrace_notify+0x2d2/0x380 kernel/signal.c:2402\n ptrace_report_syscall include/linux/ptrace.h:415 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]\n syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]\n syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218\n do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896\n\nOnline repaire on corrupted directory in f2fs_lookup() can generate\ndirty data/meta while racing w/ readonly remount, it may leave dirty\ninode after filesystem becomes readonly, however, checkpoint() will\nskips flushing dirty inode in a state of readonly mode, result in\nabove panic.\n\nLet's get rid of online repaire in f2fs_lookup(), and leave the work\nto fsck.f2fs.\n\n * CVE-2024-47692: In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: return -EINVAL when namelen is 0\n\nWhen we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may\nresult in namelen being 0, which will cause memdup_user() to return\nZERO_SIZE_PTR.\nWhen we access the name.data that has been assigned the value of\nZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is\ntriggered.\n\n[ T1205] ==================================================================\n[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260\n[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205\n[ T1205]\n[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406\n[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014\n[ T1205] Call Trace:\n[ T1205] dump_stack+0x9a/0xd0\n[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260\n[ T1205] __kasan_report.cold+0x34/0x84\n[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260\n[ T1205] kasan_report+0x3a/0x50\n[ T1205] nfs4_client_to_reclaim+0xe9/0x260\n[ T1205] ? nfsd4_release_lockowner+0x410/0x410\n[ T1205] cld_pipe_downcall+0x5ca/0x760\n[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0\n[ T1205] ? down_write_killable_nested+0x170/0x170\n[ T1205] ? avc_policy_seqno+0x28/0x40\n[ T1205] ? selinux_file_permission+0x1b4/0x1e0\n[ T1205] rpc_pipe_write+0x84/0xb0\n[ T1205] vfs_write+0x143/0x520\n[ T1205] ksys_write+0xc9/0x170\n[ T1205] ? __ia32_sys_read+0x50/0x50\n[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110\n[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110\n[ T1205] do_syscall_64+0x33/0x40\n[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1\n[ T1205] RIP: 0033:0x7fdbdb761bc7\n[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 514\n[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7\n[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008\n[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001\n[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b\n[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000\n[ T1205] ==================================================================\n\nFix it by checking namelen.\n\n * CVE-2024-47693: In the Linux kernel, the following vulnerability has been resolved:\n\nIB/core: Fix ib_cache_setup_one error flow cleanup\n\nWhen ib_cache_update return an error, we exit ib_cache_setup_one\ninstantly with no proper cleanup, even though before this we had\nalready successfully done gid_table_setup_one, that results in\nthe kernel WARN below.\n\nDo proper cleanup using gid_table_cleanup_one before returning\nthe err in order to fix the issue.\n\nWARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0\nModules linked in:\nCPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:gid_table_release_one+0x181/0x1a0\nCode: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u003c0f\u003e 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41\nRSP: 0018:ffffc90002b835b0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527\nRDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001\nRBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631\nR10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001\nR13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001\nFS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n ? show_regs+0x94/0xa0\n ? __warn+0x9e/0x1c0\n ? gid_table_release_one+0x181/0x1a0\n ? report_bug+0x1f9/0x340\n ? gid_table_release_one+0x181/0x1a0\n ? handle_bug+0xa2/0x110\n ? exc_invalid_op+0x31/0xa0\n ? asm_exc_invalid_op+0x16/0x20\n ? __warn_printk+0xc7/0x180\n ? __warn_printk+0xd4/0x180\n ? gid_table_release_one+0x181/0x1a0\n ib_device_release+0x71/0xe0\n ? __pfx_ib_device_release+0x10/0x10\n device_release+0x44/0xd0\n kobject_put+0x135/0x3d0\n put_device+0x20/0x30\n rxe_net_add+0x7d/0xa0\n rxe_newlink+0xd7/0x190\n nldev_newlink+0x1b0/0x2a0\n ? __pfx_nldev_newlink+0x10/0x10\n rdma_nl_rcv_msg+0x1ad/0x2e0\n rdma_nl_rcv_skb.constprop.0+0x176/0x210\n netlink_unicast+0x2de/0x400\n netlink_sendmsg+0x306/0x660\n __sock_sendmsg+0x110/0x120\n ____sys_sendmsg+0x30e/0x390\n ___sys_sendmsg+0x9b/0xf0\n ? kstrtouint+0x6e/0xa0\n ? kstrtouint_from_user+0x7c/0xb0\n ? get_pid_task+0xb0/0xd0\n ? proc_fail_nth_write+0x5b/0x140\n ? __fget_light+0x9a/0x200\n ? preempt_count_add+0x47/0xa0\n __sys_sendmsg+0x61/0xd0\n do_syscall_64+0x50/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n * CVE-2024-47695: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds\n\nIn the function init_conns(), after the create_con() and create_cm() for\nloop if something fails. In the cleanup for loop after the destroy tag, we\naccess out of bound memory because cid is set to clt_path-\u003es.con_num.\n\nThis commits resets the cid to clt_path-\u003es.con_num - 1, to stay in bounds\nin the cleanup loop later.\n\n * CVE-2024-47696: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency\n\nIn the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to\ndestroying CM IDs\"), the function flush_workqueue is invoked to flush the\nwork queue iwcm_wq.\n\nBut at that time, the work queue iwcm_wq was created via the function\nalloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.\n\nBecause the current process is trying to flush the whole iwcm_wq, if\niwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current\nprocess is not reclaiming memory or running on a workqueue which doesn't\nhave the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee\nleading to a deadlock.\n\nThe call trace is as below:\n\n[ 125.350876][ T1430] Call Trace:\n[ 125.356281][ T1430] \u003cTASK\u003e\n[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)\n[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))\n[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)\n[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)\n[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)\n[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))\n[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))\n[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)\n[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)\n[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm\n[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)\n[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)\n[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm\n[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma\n[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma\n[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)\n[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)\n[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)\n[ 125.531837][ T1430] kthread (kernel/kthread.c:389)\n[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)\n[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)\n[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)\n[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)\n[ 125.566487][ T1430] \u003c/TASK\u003e\n[ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---\n\n * CVE-2024-47697: In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error\n\nEnsure index in rtl2830_pid_filter does not exceed 31 to prevent\nout-of-bounds access.\n\ndev-\u003efilters is a 32-bit value, so set_bit and clear_bit functions should\nonly operate on indices from 0 to 31. If index is 32, it will attempt to\naccess a non-existent 33rd bit, leading to out-of-bounds access.\nChange the boundary check from index \u003e 32 to index \u003e= 32 to resolve this\nissue.\n\n * CVE-2024-47698: In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error\n\nEnsure index in rtl2832_pid_filter does not exceed 31 to prevent\nout-of-bounds access.\n\ndev-\u003efilters is a 32-bit value, so set_bit and clear_bit functions should\nonly operate on indices from 0 to 31. If index is 32, it will attempt to\naccess a non-existent 33rd bit, leading to out-of-bounds access.\nChange the boundary check from index \u003e 32 to index \u003e= 32 to resolve this\nissue.\n\n[hverkuil: added fixes tag, rtl2830_pid_filter -\u003e rtl2832_pid_filter in logmsg]\n\n * CVE-2024-47699: In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential null-ptr-deref in nilfs_btree_insert()\n\nPatch series \"nilfs2: fix potential issues with empty b-tree nodes\".\n\nThis series addresses three potential issues with empty b-tree nodes that\ncan occur with corrupted filesystem images, including one recently\ndiscovered by syzbot.\n\n\nThis patch (of 3):\n\nIf a b-tree is broken on the device, and the b-tree height is greater than\n2 (the level of the root node is greater than 1) even if the number of\nchild nodes of the b-tree root is 0, a NULL pointer dereference occurs in\nnilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().\n\nThis is because, when the number of child nodes of the b-tree root is 0,\nnilfs_btree_do_lookup() does not set the block buffer head in any of\npath[x].bp_bh, leaving it as the initial value of NULL, but if the level\nof the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),\nwhich accesses the buffer memory of path[x].bp_bh, is called.\n\nFix this issue by adding a check to nilfs_btree_root_broken(), which\nperforms sanity checks when reading the root node from the device, to\ndetect this inconsistency.\n\nThanks to Lizhi Xu for trying to solve the bug and clarifying the cause\nearly on.\n\n * CVE-2024-47701: In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid OOB when system.data xattr changes underneath the filesystem\n\nWhen looking up for an entry in an inlined directory, if e_value_offs is\nchanged underneath the filesystem by some change in the block device, it\nwill lead to an out-of-bounds access that KASAN detects as an UAF.\n\nEXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.\nloop0: detected capacity change from 2048 to 2047\n==================================================================\nBUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500\nRead of size 1 at addr ffff88803e91130f by task syz-executor269/5103\n\nCPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:93 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500\n ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697\n __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573\n ext4_lookup_entry fs/ext4/namei.c:1727 [inline]\n ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795\n lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633\n filename_create+0x297/0x540 fs/namei.c:3980\n do_symlinkat+0xf9/0x3a0 fs/namei.c:4587\n __do_sys_symlinkat fs/namei.c:4610 [inline]\n __se_sys_symlinkat fs/namei.c:4607 [inline]\n __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f3e73ced469\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a\nRAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469\nRDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0\nRBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290\nR10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c\nR13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0\n \u003c/TASK\u003e\n\nCalling ext4_xattr_ibody_find right after reading the inode with\next4_get_inode_loc will lead to a check of the validity of the xattrs,\navoiding this problem.\n\n * CVE-2024-47705: In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix potential invalid pointer dereference in blk_add_partition\n\nThe blk_add_partition() function initially used a single if-condition\n(IS_ERR(part)) to check for errors when adding a partition. This was\nmodified to handle the specific case of -ENXIO separately, allowing the\nfunction to proceed without logging the error in this case. However,\nthis change unintentionally left a path where md_autodetect_dev()\ncould be called without confirming that part is a valid pointer.\n\nThis commit separates the error handling logic by splitting the\ninitial if-condition, improving code readability and handling specific\nerror scenarios explicitly. The function now distinguishes the general\nerror case from -ENXIO without altering the existing behavior of\nmd_autodetect_dev() calls.\n\n * CVE-2024-47706: In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix possible UAF for bfqq-\u003ebic with merge chain\n\n1) initial state, three tasks:\n\n\t\tProcess 1 Process 2\tProcess 3\n\t\t (BIC1) (BIC2)\t\t (BIC3)\n\t\t | ? | ?\t\t | ?\n\t\t | | | |\t\t | |\n\t\t V | V |\t\t V |\n\t\t bfqq1 bfqq2\t\t bfqq3\nprocess ref:\t 1\t\t 1\t\t 1\n\n2) bfqq1 merged to bfqq2:\n\n\t\tProcess 1 Process 2\tProcess 3\n\t\t (BIC1) (BIC2)\t\t (BIC3)\n\t\t | |\t\t | ?\n\t\t \\--------------\\|\t\t | |\n\t\t V\t\t V |\n\t\t bfqq1---------\u003ebfqq2\t\t bfqq3\nprocess ref:\t 0\t\t 2\t\t 1\n\n3) bfqq2 merged to bfqq3:\n\n\t\tProcess 1 Process 2\tProcess 3\n\t\t (BIC1) (BIC2)\t\t (BIC3)\n\t here -\u003e ? |\t\t |\n\t\t \\--------------\\ \\-------------\\|\n\t\t V\t\t V\n\t\t bfqq1---------\u003ebfqq2----------\u003ebfqq3\nprocess ref:\t 0\t\t 1\t\t 3\n\nIn this case, IO from Process 1 will get bfqq2 from BIC1 first, and then\nget bfqq3 through merge chain, and finially handle IO by bfqq3.\nHowerver, current code will think bfqq2 is owned by BIC1, like initial\nstate, and set bfqq2-\u003ebic to BIC1.\n\nbfq_insert_request\n-\u003e by Process 1\n bfqq = bfq_init_rq(rq)\n bfqq = bfq_get_bfqq_handle_split\n bfqq = bic_to_bfqq\n -\u003e get bfqq2 from BIC1\n bfqq-\u003eref++\n rq-\u003eelv.priv[0] = bic\n rq-\u003eelv.priv[1] = bfqq\n if (bfqq_process_refs(bfqq) == 1)\n bfqq-\u003ebic = bic\n -\u003e record BIC1 to bfqq2\n\n __bfq_insert_request\n new_bfqq = bfq_setup_cooperator\n -\u003e get bfqq3 from bfqq2-\u003enew_bfqq\n bfqq_request_freed(bfqq)\n new_bfqq-\u003eref++\n rq-\u003eelv.priv[1] = new_bfqq\n -\u003e handle IO by bfqq3\n\nFix the problem by checking bfqq is from merge chain fist. And this\nmight fix a following problem reported by our syzkaller(unreproducible):\n\n==================================================================\nBUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]\nBUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]\nBUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889\nWrite of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595\n\nCPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_requeue_work\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0x10d/0x610 mm/kasan/report.c:475\n kasan_report+0x8e/0xc0 mm/kasan/report.c:588\n bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]\n bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]\n bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889\n bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757\n bfq_init_rq block/bfq-iosched.c:6876 [inline]\n bfq_insert_request block/bfq-iosched.c:6254 [inline]\n bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304\n blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593\n blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502\n process_one_work kernel/workqueue.c:2627 [inline]\n process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700\n worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781\n kthread+0x33c/0x440 kernel/kthread.c:388\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305\n \u003c/TASK\u003e\n\nAllocated by task 20776:\n kasan_save_stack+0x20/0x40 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328\n kasan_slab_alloc include/linux/kasan.h:188 [inline]\n slab_post_alloc_hook mm/slab.h:763 [inline]\n slab_alloc_node mm/slub.c:3458 [inline]\n kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503\n ioc_create_icq block/blk-ioc.c:370 [inline]\n---truncated---\n\n * CVE-2024-47707: In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()\n\nBlamed commit accidentally removed a check for rt-\u003ert6i_idev being NULL,\nas spotted by syzbot:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\n RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]\n RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914\nCode: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df \u003c80\u003e 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06\nRSP: 0018:ffffc900047374e0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0\nRBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c\nR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18\nR13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930\nFS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856\n addrconf_notify+0x3cb/0x1020\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352\n unregister_netdevice_many net/core/dev.c:11414 [inline]\n unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289\n unregister_netdevice include/linux/netdevice.h:3129 [inline]\n __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685\n tun_detach drivers/net/tun.c:701 [inline]\n tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510\n __fput+0x24a/0x8a0 fs/file_table.c:422\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0xa2f/0x27f0 kernel/exit.c:882\n do_group_exit+0x207/0x2c0 kernel/exit.c:1031\n __do_sys_exit_group kernel/exit.c:1042 [inline]\n __se_sys_exit_group kernel/exit.c:1040 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040\n x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f1acc77def9\nCode: Unable to access opcode bytes at 0x7f1acc77decf.\nRSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043\nRBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0\n \u003c/TASK\u003e\nModules linked in:\n---[ end trace 0000000000000000 ]---\n RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]\n RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914\nCode: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df \u003c80\u003e 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06\nRSP: 0018:ffffc900047374e0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0\nR\n---truncated---\n\n * CVE-2024-47709: In the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: Clear bo-\u003ebcm_proc_read after remove_proc_entry().\n\nsyzbot reported a warning in bcm_release(). [0]\n\nThe blamed change fixed another warning that is triggered when\nconnect() is issued again for a socket whose connect()ed device has\nbeen unregistered.\n\nHowever, if the socket is just close()d without the 2nd connect(), the\nremaining bo-\u003ebcm_proc_read triggers unnecessary remove_proc_entry()\nin bcm_release().\n\nLet's clear bo-\u003ebcm_proc_read after remove_proc_entry() in bcm_notify().\n\n[0]\nname '4986'\nWARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711\nModules linked in:\nCPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711\nCode: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u003c0f\u003e 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07\nRSP: 0018:ffffc9000345fa20 EFLAGS: 00010246\nRAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a\nR10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640\nR13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n bcm_release+0x250/0x880 net/can/bcm.c:1578\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbc/0x240 net/socket.c:1421\n __fput+0x24a/0x8a0 fs/file_table.c:422\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0xa2f/0x27f0 kernel/exit.c:882\n do_group_exit+0x207/0x2c0 kernel/exit.c:1031\n __do_sys_exit_group kernel/exit.c:1042 [inline]\n __se_sys_exit_group kernel/exit.c:1040 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040\n x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fcfb51ee969\nCode: Unable to access opcode bytes at 0x7fcfb51ee93f.\nRSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\nRBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000\nR10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0\nR13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160\n \u003c/TASK\u003e\n\n * CVE-2024-47710: In the Linux kernel, the following vulnerability has been resolved:\n\nsock_map: Add a cond_resched() in sock_hash_free()\n\nSeveral syzbot soft lockup reports all have in common sock_hash_free()\n\nIf a map with a large number of buckets is destroyed, we need to yield\nthe cpu when needed.\n\n * CVE-2024-47712: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param\n\nIn the `wilc_parse_join_bss_param` function, the TSF field of the `ies`\nstructure is accessed after the RCU read-side critical section is\nunlocked. According to RCU usage rules, this is illegal. Reusing this\npointer can lead to unpredictable behavior, including accessing memory\nthat has been updated or causing use-after-free issues.\n\nThis possible bug was identified using a static analysis tool developed\nby myself, specifically designed to detect RCU-related issues.\n\nTo address this, the TSF value is now stored in a local variable\n`ies_tsf` before the RCU lock is released. The `param-\u003etsf_lo` field is\nthen assigned using this local variable, ensuring that the TSF value is\nsafely accessed.\n\n * CVE-2024-47713: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()\n\nSince '__dev_queue_xmit()' should be called with interrupts enabled,\nthe following backtrace:\n\nieee80211_do_stop()\n ...\n spin_lock_irqsave(\u0026local-\u003equeue_stop_reason_lock, flags)\n ...\n ieee80211_free_txskb()\n ieee80211_report_used_skb()\n ieee80211_report_ack_skb()\n cfg80211_mgmt_tx_status_ext()\n nl80211_frame_tx_status()\n genlmsg_multicast_netns()\n genlmsg_multicast_netns_filtered()\n nlmsg_multicast_filtered()\n\t netlink_broadcast_filtered()\n\t do_one_broadcast()\n\t netlink_broadcast_deliver()\n\t __netlink_sendskb()\n\t netlink_deliver_tap()\n\t __netlink_deliver_tap_skb()\n\t dev_queue_xmit()\n\t __dev_queue_xmit() ; with IRQS disabled\n ...\n spin_unlock_irqrestore(\u0026local-\u003equeue_stop_reason_lock, flags)\n\nissues the warning (as reported by syzbot reproducer):\n\nWARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120\n\nFix this by implementing a two-phase skb reclamation in\n'ieee80211_do_stop()', where actual work is performed\noutside of a section with interrupts disabled.\n\n * CVE-2024-47718: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: always wait for both firmware loading attempts\n\nIn 'rtw_wait_firmware_completion()', always wait for both (regular and\nwowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'\nhas failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue\n'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually\nthe wowlan one) is still in progress, causing UAF detected by KASAN.\n\n * CVE-2024-47720: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func\n\nThis commit adds a null check for the set_output_gamma function pointer\nin the dcn30_set_output_transfer_func function. Previously,\nset_output_gamma was being checked for nullity at line 386, but then it\nwas being dereferenced without any nullity check at line 401. This\ncould potentially lead to a null pointer dereference error if\nset_output_gamma is indeed null.\n\nTo fix this, we now ensure that set_output_gamma is not null before\ndereferencing it. We do this by adding a nullity check for\nset_output_gamma before the call to set_output_gamma at line 401. If\nset_output_gamma is null, we log an error message and do not call the\nfunction.\n\nThis fix prevents a potential null pointer dereference error.\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()\nerror: we previously assumed 'mpc-\u003efuncs-\u003eset_output_gamma' could be null (see line 386)\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c\n 373 bool dcn30_set_output_transfer_func(struct dc *dc,\n 374 struct pipe_ctx *pipe_ctx,\n 375 const struct dc_stream_state *stream)\n 376 {\n 377 int mpcc_id = pipe_ctx-\u003eplane_res.hubp-\u003einst;\n 378 struct mpc *mpc = pipe_ctx-\u003estream_res.opp-\u003ectx-\u003edc-\u003eres_pool-\u003empc;\n 379 const struct pwl_params *params = NULL;\n 380 bool ret = false;\n 381\n 382 /* program OGAM or 3DLUT only for the top pipe*/\n 383 if (pipe_ctx-\u003etop_pipe == NULL) {\n 384 /*program rmu shaper and 3dlut in MPC*/\n 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);\n 386 if (ret == false \u0026\u0026 mpc-\u003efuncs-\u003eset_output_gamma) {\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL\n\n 387 if (stream-\u003eout_transfer_func.type == TF_TYPE_HWPWL)\n 388 params = \u0026stream-\u003eout_transfer_func.pwl;\n 389 else if (pipe_ctx-\u003estream-\u003eout_transfer_func.type ==\n 390 TF_TYPE_DISTRIBUTED_POINTS \u0026\u0026\n 391 cm3_helper_translate_curve_to_hw_format(\n 392 \u0026stream-\u003eout_transfer_func,\n 393 \u0026mpc-\u003eblender_params, false))\n 394 params = \u0026mpc-\u003eblender_params;\n 395 /* there are no ROM LUTs in OUTGAM */\n 396 if (stream-\u003eout_transfer_func.type == TF_TYPE_PREDEFINED)\n 397 BREAK_TO_DEBUGGER();\n 398 }\n 399 }\n 400\n--\u003e 401 mpc-\u003efuncs-\u003eset_output_gamma(mpc, mpcc_id, params);\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash\n\n 402 return ret;\n 403 }\n\n * CVE-2024-47723: In the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix out-of-bounds in dbNextAG() and diAlloc()\n\nIn dbNextAG() , there is no check for the case where bmp-\u003edb_numag is\ngreater or same than MAXAG due to a polluted image, which causes an\nout-of-bounds. Therefore, a bounds check should be added in dbMount().\n\nAnd in dbNextAG(), a check for the case where agpref is greater than\nbmp-\u003edb_numag should be added, so an out-of-bounds exception should be\nprevented.\n\nAdditionally, a check for the case where agno is greater or same than\nMAXAG should be added in diAlloc() to prevent out-of-bounds.\n\n * CVE-2024-47727: In the Linux kernel, the following vulnerability has been resolved:\n\nx86/tdx: Fix \"in-kernel MMIO\" check\n\nTDX only supports kernel-initiated MMIO operations. The handle_mmio()\nfunction checks if the #VE exception occurred in the kernel and rejects\nthe operation if it did not.\n\nHowever, userspace can deceive the kernel into performing MMIO on its\nbehalf. For example, if userspace can point a syscall to an MMIO address,\nsyscall does get_user() or put_user() on it, triggering MMIO #VE. The\nkernel will treat the #VE as in-kernel MMIO.\n\nEnsure that the target MMIO address is within the kernel before decoding\ninstruction.\n\n * CVE-2024-47728: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error\n\nFor all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input\narguments, zero the value for the case of an error as otherwise it could leak\nmemory. For tracing, it is not needed given CAP_PERFMON can already read all\nkernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped\nin here.\n\nAlso, the MTU helpers mtu_len pointer value is being written but also read.\nTechnically, the MEM_UNINIT should not be there in order to always force init.\nRemoving MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now\nimplies two things actually: i) write into memory, ii) memory does not have\nto be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,\nii) memory must be initialized. This means that for bpf_*_check_mtu() we're\nreadding the issue we're trying to fix, that is, it would then be able to\nwrite back into things like .rodata BPF maps. Follow-up work will rework the\nMEM_UNINIT semantics such that the intent can be better expressed. For now\njust clear the *mtu_len on error path which can be lifted later again.\n\n * CVE-2024-47730: In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - inject error before stopping queue\n\nThe master ooo cannot be completely closed when the\naccelerator core reports memory error. Therefore, the driver\nneeds to inject the qm error to close the master ooo. Currently,\nthe qm error is injected after stopping queue, memory may be\nreleased immediately after stopping queue, causing the device to\naccess the released memory. Therefore, error is injected to close master\nooo before stopping queue to ensure that the device does not access\nthe released memory.\n\n * CVE-2024-47731: In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: Fix ali_drw_pmu driver interrupt status clearing\n\nThe alibaba_uncore_pmu driver forgot to clear all interrupt status\nin the interrupt processing function. After the PMU counter overflow\ninterrupt occurred, an interrupt storm occurred, causing the system\nto hang.\n\nTherefore, clear the correct interrupt status in the interrupt handling\nfunction to fix it.\n\n * CVE-2024-47734: In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()\n\nsyzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce\nthis[1], one bond device (bond1) has xdpdrv, which increases\nbpf_master_redirect_enabled_key. Another bond device (bond0) which is\nunsupported by XDP but its slave (veth3) has xdpgeneric that returns\nXDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect().\nTo reduce unnecessary warnings and improve log management, we need to\ndelete the WARN_ON_ONCE() and add ratelimit to the netdev_err().\n\n[1] Steps to reproduce:\n # Needs tx_xdp with return XDP_TX;\n ip l add veth0 type veth peer veth1\n ip l add veth3 type veth peer veth4\n ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP\n ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default\n ip l set veth0 master bond1\n ip l set bond1 up\n # Increases bpf_master_redirect_enabled_key\n ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx\n ip l set veth3 master bond0\n ip l set bond0 up\n ip l set veth4 up\n # Triggers WARN_ON_ONCE() from the xdp_master_redirect()\n ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx\n\n * CVE-2024-47735: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled\n\nFix missuse of spin_lock_irq()/spin_unlock_irq() when\nspin_lock_irqsave()/spin_lock_irqrestore() was hold.\n\nThis was discovered through the lock debugging, and the corresponding\nlog is as follows:\n\nraw_local_irq_restore() called with IRQs enabled\nWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40\n...\nCall trace:\n warn_bogus_irq_restore+0x30/0x40\n _raw_spin_unlock_irqrestore+0x84/0xc8\n add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]\n hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]\n hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]\n create_qp+0x138/0x258\n ib_create_qp_kernel+0x50/0xe8\n create_mad_qp+0xa8/0x128\n ib_mad_port_open+0x218/0x448\n ib_mad_init_device+0x70/0x1f8\n add_client_context+0xfc/0x220\n enable_device_and_get+0xd0/0x140\n ib_register_device.part.0+0xf4/0x1c8\n ib_register_device+0x34/0x50\n hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]\n hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]\n hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]\n\n * CVE-2024-47737: In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call cache_put if xdr_reserve_space returns NULL\n\nIf not enough buffer space available, but idmap_lookup has triggered\nlookup_fn which calls cache_get and returns successfully. Then we\nmissed to call cache_put here which pairs with cache_get.\n\nReviwed-by: Jeff Layton \u003cjlayton@kernel.org\u003e\n\n * CVE-2024-47738: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don't use rate mask for offchannel TX either\n\nLike the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for\nscanning\"), ignore incorrect settings to avoid no supported rate warning\nreported by syzbot.\n\nThe syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211:\nfix default HE tx bitrate mask in 2G band\"), which however corrects\nbitmask of HE MCS and recognizes correctly settings of empty legacy rate\nplus HE MCS rate instead of returning -EINVAL.\n\nAs suggestions [1], follow the change of SCAN TX to consider this case of\noffchannel TX as well.\n\n[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024\n\n * CVE-2024-47739: In the Linux kernel, the following vulnerability has been resolved:\n\npadata: use integer wrap around to prevent deadlock on seq_nr overflow\n\nWhen submitting more than 2^32 padata objects to padata_do_serial, the\ncurrent sorting implementation incorrectly sorts padata objects with\noverflowed seq_nr, causing them to be placed before existing objects in\nthe reorder list. This leads to a deadlock in the serialization process\nas padata_find_next cannot match padata-\u003eseq_nr and pd-\u003eprocessed\nbecause the padata instance with overflowed seq_nr will be selected\nnext.\n\nTo fix this, we use an unsigned integer wrap around to correctly sort\npadata objects in scenarios with integer overflow.\n\n * CVE-2024-47742: In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware_loader: Block path traversal\n\nMost firmware names are hardcoded strings, or are constructed from fairly\nconstrained format strings where the dynamic parts are just some hex\nnumbers or such.\n\nHowever, there are a couple codepaths in the kernel where firmware file\nnames contain string components that are passed through from a device or\nsemi-privileged userspace; the ones I could find (not counting interfaces\nthat require root privileges) are:\n\n - lpfc_sli4_request_firmware_update() seems to construct the firmware\n filename from \"ModelName\", a string that was previously parsed out of\n some descriptor (\"Vital Product Data\") in lpfc_fill_vpd()\n - nfp_net_fw_find() seems to construct a firmware filename from a model\n name coming from nfp_hwinfo_lookup(pf-\u003ehwinfo, \"nffw.partno\"), which I\n think parses some descriptor that was read from the device.\n (But this case likely isn't exploitable because the format string looks\n like \"netronome/nic_%s\", and there shouldn't be any *folders* starting\n with \"netronome/nic_\". The previous case was different because there,\n the \"%s\" is *at the start* of the format string.)\n - module_flash_fw_schedule() is reachable from the\n ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as\n GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is\n enough to pass the privilege check), and takes a userspace-provided\n firmware name.\n (But I think to reach this case, you need to have CAP_NET_ADMIN over a\n network namespace that a special kind of ethernet device is mapped into,\n so I think this is not a viable attack path in practice.)\n\nFix it by rejecting any firmware names containing \"..\" path components.\n\nFor what it's worth, I went looking and haven't found any USB device\ndrivers that use the firmware loader dangerously.\n\n * CVE-2024-47743: In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: prevent NULL pointer dereference in find_asymmetric_key()\n\nIn find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2}\narguments, the kernel will first emit WARN but then have an oops\nbecause id_2 gets dereferenced anyway.\n\nAdd the missing id_2 check and move WARN_ON() to the final else branch\nto avoid duplicate NULL checks.\n\nFound by Linux Verification Center (linuxtesting.org) with Svace static\nanalysis tool.\n\n * CVE-2024-47747: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition\n\nIn the ether3_probe function, a timer is initialized with a callback\nfunction ether3_ledoff, bound to \u0026prev(dev)-\u003etimer. Once the timer is\nstarted, there is a risk of a race condition if the module or device\nis removed, triggering the ether3_remove function to perform cleanup.\nThe sequence of operations that may lead to a UAF bug is as follows:\n\nCPU0 CPU1\n\n | ether3_ledoff\nether3_remove |\n free_netdev(dev); |\n put_devic |\n kfree(dev); |\n | ether3_outw(priv(dev)-\u003eregs.config2 |= CFG2_CTRLO, REG_CONFIG2);\n | // use dev\n\nFix it by ensuring that the timer is canceled before proceeding with\nthe cleanup in ether3_remove.\n\n * CVE-2024-47748: In the Linux kernel, the following vulnerability has been resolved:\n\nvhost_vdpa: assign irq bypass producer token correctly\n\nWe used to call irq_bypass_unregister_producer() in\nvhost_vdpa_setup_vq_irq() which is problematic as we don't know if the\ntoken pointer is still valid or not.\n\nActually, we use the eventfd_ctx as the token so the life cycle of the\ntoken should be bound to the VHOST_SET_VRING_CALL instead of\nvhost_vdpa_setup_vq_irq() which could be called by set_status().\n\nFixing this by setting up irq bypass producer's token when handling\nVHOST_SET_VRING_CALL and un-registering the producer before calling\nvhost_vring_ioctl() to prevent a possible use after free as eventfd\ncould have been released in vhost_vring_ioctl(). And such registering\nand unregistering will only be done if DRIVER_OK is set.\n\n * CVE-2024-47749: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cxgb4: Added NULL check for lookup_atid\n\nThe lookup_atid() function can return NULL if the ATID is\ninvalid or does not exist in the identifier table, which\ncould lead to dereferencing a null pointer without a\ncheck in the `act_establish()` and `act_open_rpl()` functions.\nAdd a NULL check to prevent null pointer dereferencing.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n * CVE-2024-47750: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix Use-After-Free of rsv_qp on HIP08\n\nCurrently rsv_qp is freed before ib_unregister_device() is called\non HIP08. During the time interval, users can still dereg MR and\nrsv_qp will be used in this process, leading to a UAF. Move the\nrelease of rsv_qp after calling ib_unregister_device() to fix it.\n\n * CVE-2024-47751: In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()\n\nWithin kirin_pcie_parse_port(), the pcie-\u003enum_slots is compared to\npcie-\u003egpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead\nto an overflow.\n\nThus, fix condition to pcie-\u003enum_slots + 1 \u003e= MAX_PCI_SLOTS and move\npcie-\u003enum_slots increment below the if-statement to avoid out-of-bounds\narray access.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[kwilczynski: commit log]\n\n * CVE-2024-47756: In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: keystone: Fix if-statement expression in ks_pcie_quirk()\n\nThis code accidentally uses \u0026\u0026 where || was intended. It potentially\nresults in a NULL dereference.\n\nThus, fix the if-statement expression to use the correct condition.\n\n[kwilczynski: commit log]\n\n * CVE-2024-47757: In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential oob read in nilfs_btree_check_delete()\n\nThe function nilfs_btree_check_delete(), which checks whether degeneration\nto direct mapping occurs before deleting a b-tree entry, causes memory\naccess outside the block buffer when retrieving the maximum key if the\nroot node has no entries.\n\nThis does not usually happen because b-tree mappings with 0 child nodes\nare never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen\nif the b-tree root node read from a device is configured that way, so fix\nthis potential issue by adding a check for that case.\n\n * CVE-2024-49850: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos\n\nIn case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL\nreferencing a non-existing BTF type, function bpf_core_calc_relo_insn\nwould cause a null pointer deference.\n\nFix this by adding a proper check upper in call stack, as malformed\nrelocation records could be passed from user space.\n\nSimplest reproducer is a program:\n\n r0 = 0\n exit\n\nWith a single relocation record:\n\n .insn_off = 0, /* patch first instruction */\n .type_id = 100500, /* this type id does not exist */\n .access_str_off = 6, /* offset of string \"0\" */\n .kind = BPF_CORE_TYPE_ID_LOCAL,\n\nSee the link for original reproducer or next commit for a test case.\n\n * CVE-2024-49851: In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Clean up TPM space after command failure\n\ntpm_dev_transmit prepares the TPM space before attempting command\ntransmission. However if the command fails no rollback of this\npreparation is done. This can result in transient handles being leaked\nif the device is subsequently closed with no further commands performed.\n\nFix this by flushing the space in the event of command transmission\nfailure.\n\n * CVE-2024-49852: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()\n\nThe kref_put() function will call nport-\u003erelease if the refcount drops to\nzero. The nport-\u003erelease release function is _efc_nport_free() which frees\n\"nport\". But then we dereference \"nport\" on the next line which is a use\nafter free. Re-order these lines to avoid the use after free.\n\n * CVE-2024-49853: In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scmi: Fix double free in OPTEE transport\n\nChannels can be shared between protocols, avoid freeing the same channel\ndescriptors twice when unloading the stack.\n\n * CVE-2024-49854: In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix uaf for accessing waker_bfqq after splitting\n\nAfter commit 42c306ed7233 (\"block, bfq: don't break merge chain in\nbfq_split_bfqq()\"), if the current procress is the last holder of bfqq,\nthe bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and\nthen access bfqq-\u003ewaker_bfqq may trigger UAF. What's more, the waker_bfqq\nmay in the merge chain of bfqq, hence just recored waker_bfqq is still\nnot safe.\n\nFix the problem by adding a helper bfq_waker_bfqq() to check if\nbfqq-\u003ewaker_bfqq is in the merge chain, and current procress is the only\nholder.\n\n * CVE-2024-49855: In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix race between timeout and normal completion\n\nIf request timetout is handled by nbd_requeue_cmd(), normal completion\nhas to be stopped for avoiding to complete this requeued request, other\nuse-after-free can be triggered.\n\nFix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime\nmake sure that cmd-\u003elock is grabbed for clearing the flag and the\nrequeue.\n\n * CVE-2024-49856: In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Fix deadlock in SGX NUMA node search\n\nWhen the current node doesn't have an EPC section configured by firmware\nand all other EPC sections are used up, CPU can get stuck inside the\nwhile loop that looks for an available EPC page from remote nodes\nindefinitely, leading to a soft lockup. Note how nid_of_current will\nnever be equal to nid in that while loop because nid_of_current is not\nset in sgx_numa_mask.\n\nAlso worth mentioning is that it's perfectly fine for the firmware not\nto setup an EPC section on a node. While setting up an EPC section on\neach node can enhance performance, it is not a requirement for\nfunctionality.\n\nRework the loop to start and end on *a* node that has SGX memory. This\navoids the deadlock looking for the current SGX-lacking node to show up\nin the loop when it never will.\n\n * CVE-2024-49858: In the Linux kernel, the following vulnerability has been resolved:\n\nefistub/tpm: Use ACPI reclaim memory for event log to avoid corruption\n\nThe TPM event log table is a Linux specific construct, where the data\nproduced by the GetEventLog() boot service is cached in memory, and\npassed on to the OS using an EFI configuration table.\n\nThe use of EFI_LOADER_DATA here results in the region being left\nunreserved in the E820 memory map constructed by the EFI stub, and this\nis the memory description that is passed on to the incoming kernel by\nkexec, which is therefore unaware that the region should be reserved.\n\nEven though the utility of the TPM2 event log after a kexec is\nquestionable, any corruption might send the parsing code off into the\nweeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY\ninstead, which is always treated as reserved by the E820 conversion\nlogic.\n\n * CVE-2024-49859: In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to check atomic_file in f2fs ioctl interfaces\n\nSome f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),\nf2fs_move_file_range(), and f2fs_defragment_range() missed to\ncheck atomic_write status, which may cause potential race issue,\nfix it.\n\n * CVE-2024-49860: In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: sysfs: validate return type of _STR method\n\nOnly buffer objects are valid return values of _STR.\n\nIf something else is returned description_show() will access invalid\nmemory.\n\n * CVE-2024-49863: In the Linux kernel, the following vulnerability has been resolved:\n\nvhost/scsi: null-ptr-dereference in vhost_scsi_get_req()\n\nSince commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code\nfrom control queue handler\") a null pointer dereference bug can be\ntriggered when guest sends an SCSI AN request.\n\nIn vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with\n`\u0026v_req.tmf.lun[1]` within a switch-case block and is then passed to\nvhost_scsi_get_req() which extracts `vc-\u003ereq` and `tpg`. However, for\na `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is\nset to NULL in this branch. Later, in vhost_scsi_get_req(),\n`vc-\u003etarget` is dereferenced without being checked, leading to a null\npointer dereference bug. This bug can be triggered from guest.\n\nWhen this bug occurs, the vhost_worker process is killed while holding\n`vq-\u003emutex` and the corresponding tpg will remain occupied\nindefinitely.\n\nBelow is the KASAN report:\nOops: general protection fault, probably for non-canonical address\n0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1\nHardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS\n1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:vhost_scsi_get_req+0x165/0x3a0\nCode: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 \u003c0f\u003e b6\n04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00\nRSP: 0018:ffff888017affb50 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8\nRBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000\nFS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0\nCall Trace:\n \u003cTASK\u003e\n ? show_regs+0x86/0xa0\n ? die_addr+0x4b/0xd0\n ? exc_general_protection+0x163/0x260\n ? asm_exc_general_protection+0x27/0x30\n ? vhost_scsi_get_req+0x165/0x3a0\n vhost_scsi_ctl_handle_vq+0x2a4/0xca0\n ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10\n ? __switch_to+0x721/0xeb0\n ? __schedule+0xda5/0x5710\n ? __kasan_check_write+0x14/0x30\n ? _raw_spin_lock+0x82/0xf0\n vhost_scsi_ctl_handle_kick+0x52/0x90\n vhost_run_work_list+0x134/0x1b0\n vhost_task_fn+0x121/0x350\n...\n \u003c/TASK\u003e\n---[ end trace 0000000000000000 ]---\n\nLet's add a check in vhost_scsi_get_req.\n\n[whitespace fixes]\n\n * CVE-2024-49871: In the Linux kernel, the following vulnerability has been resolved:\n\nInput: adp5589-keys - fix NULL pointer dereference\n\nWe register a devm action to call adp5589_clear_config() and then pass\nthe i2c client as argument so that we can call i2c_get_clientdata() in\norder to get our device object. However, i2c_set_clientdata() is only\nbeing set at the end of the probe function which means that we'll get a\nNULL pointer dereference in case the probe function fails early.\n\n * CVE-2024-49875: In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: map the EBADMSG to nfserr_io to avoid warning\n\nExt4 will throw -EBADMSG through ext4_readdir when a checksum error\noccurs, resulting in the following WARNING.\n\nFix it by mapping EBADMSG to nfserr_io.\n\nnfsd_buffered_readdir\n iterate_dir // -EBADMSG -74\n ext4_readdir // .iterate_shared\n ext4_dx_readdir\n ext4_htree_fill_tree\n htree_dirblock_to_tree\n ext4_read_dirblock\n __ext4_read_dirblock\n ext4_dirblock_csum_verify\n warn_no_space_for_csum\n __warn_no_space_for_csum\n return ERR_PTR(-EFSBADCRC) // -EBADMSG -74\n nfserrno // WARNING\n\n[ 161.115610] ------------[ cut here ]------------\n[ 161.116465] nfsd: non-standard errno: -74\n[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0\n[ 161.118596] Modules linked in:\n[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138\n[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe\nmu.org 04/01/2014\n[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0\n[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6\n 05 ce 2b 61 03 01 e8 99 20 d8 00 \u003c0f\u003e 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33\n[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286\n[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a\n[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827\n[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021\n[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8\n[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000\n[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0\n[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 161.141519] PKRU: 55555554\n[ 161.142076] Call Trace:\n[ 161.142575] ? __warn+0x9b/0x140\n[ 161.143229] ? nfserrno+0x9d/0xd0\n[ 161.143872] ? report_bug+0x125/0x150\n[ 161.144595] ? handle_bug+0x41/0x90\n[ 161.145284] ? exc_invalid_op+0x14/0x70\n[ 161.146009] ? asm_exc_invalid_op+0x12/0x20\n[ 161.146816] ? nfserrno+0x9d/0xd0\n[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0\n[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380\n[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0\n[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170\n[ 161.151004] ? generic_file_llseek_size+0x48/0x160\n[ 161.151895] nfsd_readdir+0x132/0x190\n[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380\n[ 161.153516] ? nfsd_unlink+0x380/0x380\n[ 161.154256] ? override_creds+0x45/0x60\n[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0\n[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210\n[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0\n[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0\n[ 161.158494] ? lock_downgrade+0x90/0x90\n[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10\n[ 161.160092] nfsd4_encode_operation+0x15a/0x440\n[ 161.160959] nfsd4_proc_compound+0x718/0xe90\n[ 161.161818] nfsd_dispatch+0x18e/0x2c0\n[ 161.162586] svc_process_common+0x786/0xc50\n[ 161.163403] ? nfsd_svc+0x380/0x380\n[ 161.164137] ? svc_printk+0x160/0x160\n[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380\n[ 161.165808] ? nfsd_svc+0x380/0x380\n[ 161.166523] ? rcu_is_watching+0x23/0x40\n[ 161.167309] svc_process+0x1a5/0x200\n[ 161.168019] nfsd+0x1f5/0x380\n[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260\n[ 161.169554] kthread+0x1c4/0x210\n[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80\n[ 161.171246] ret_from_fork+0x1f/0x30\n\n * CVE-2024-49877: In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate\n\nWhen doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger\nNULL pointer dereference in the following ocfs2_set_buffer_uptodate() if\nbh is NULL.\n\n * CVE-2024-49879: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: omapdrm: Add missing check for alloc_ordered_workqueue\n\nAs it may return NULL pointer and cause NULL pointer dereference. Add check\nfor the return value of alloc_ordered_workqueue.\n\n * CVE-2024-49896: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check stream before comparing them\n\n[WHAT \u0026 HOW]\namdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is\nnecessary to check for null before dereferencing them.\n\nThis fixes 1 FORWARD_NULL issue reported by Coverity.\n\n * CVE-2024-49905: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)\n\nThis commit adds a null check for the 'afb' variable in the\namdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was\nassumed to be null, but was used later in the code without a null check.\nThis could potentially lead to a null pointer dereference.\n\nChanges since v1:\n- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)\n\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)\n\n * CVE-2024-49907: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check null pointers before using dc-\u003eclk_mgr\n\n[WHY \u0026 HOW]\ndc-\u003eclk_mgr is null checked previously in the same function, indicating\nit might be null.\n\nPassing \"dc\" to \"dc-\u003ehwss.apply_idle_power_optimizations\", which\ndereferences null \"dc-\u003eclk_mgr\". (The function pointer resolves to\n\"dcn35_apply_idle_power_optimizations\".)\n\nThis fixes 1 FORWARD_NULL issue reported by Coverity.\n\n * CVE-2024-49912: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream'\n\nThis commit adds a null check for 'stream_status' in the function\n'planes_changed_for_existing_stream'. Previously, the code assumed\n'stream_status' could be null, but did not handle the case where it was\nactually null. This could lead to a null pointer dereference.\n\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)\n\n * CVE-2024-49913: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream\n\nThis commit addresses a null pointer dereference issue in the\n`commit_planes_for_stream` function at line 4140. The issue could occur\nwhen `top_pipe_to_program` is null.\n\nThe fix adds a check to ensure `top_pipe_to_program` is not null before\naccessing its stream_res. This prevents a null pointer dereference.\n\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)\n\n * CVE-2024-50033: In the Linux kernel, the following vulnerability has been resolved:\n\nslip: make slhc_remember() more robust against malicious packets\n\nsyzbot found that slhc_remember() was missing checks against\nmalicious packets [1].\n\nslhc_remember() only checked the size of the packet was at least 20,\nwhich is not good enough.\n\nWe need to make sure the packet includes the IPv4 and TCP header\nthat are supposed to be carried.\n\nAdd iph and th pointers to make the code more readable.\n\n[1]\n\nBUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666\n slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666\n ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455\n ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]\n ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212\n ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327\n pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113\n __release_sock+0x1da/0x330 net/core/sock.c:3072\n release_sock+0x6b/0x250 net/core/sock.c:3626\n pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903\n sock_sendmsg_nosec net/socket.c:729 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:744\n ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n __do_sys_sendmmsg net/socket.c:2771 [inline]\n __se_sys_sendmmsg net/socket.c:2768 [inline]\n __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1322 [inline]\n sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732\n pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867\n sock_sendmsg_nosec net/socket.c:729 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:744\n ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n __do_sys_sendmmsg net/socket.c:2771 [inline]\n __se_sys_sendmmsg net/socket.c:2768 [inline]\n __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n\n * CVE-2024-50035: In the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix ppp_async_encode() illegal access\n\nsyzbot reported an issue in ppp_async_encode() [1]\n\nIn this case, pppoe_sendmsg() is called with a zero size.\nThen ppp_async_encode() is called with an empty skb.\n\nBUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]\n ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304\n pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113\n __release_sock+0x1da/0x330 net/core/sock.c:3072\n release_sock+0x6b/0x250 net/core/sock.c:3626\n pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903\n sock_sendmsg_nosec net/socket.c:729 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:744\n ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n __do_sys_sendmmsg net/socket.c:2771 [inline]\n __se_sys_sendmmsg net/socket.c:2768 [inline]\n __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4092 [inline]\n slab_alloc_node mm/slub.c:4135 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1322 [inline]\n sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732\n pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867\n sock_sendmsg_nosec net/socket.c:729 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:744\n ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n __do_sys_sendmmsg net/socket.c:2771 [inline]\n __se_sys_sendmmsg net/socket.c:2768 [inline]\n __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n\n * CVE-2024-50041: In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix macvlan leak by synchronizing access to mac_filter_hash\n\nThis patch addresses a macvlan leak issue in the i40e driver caused by\nconcurrent access to vsi-\u003emac_filter_hash. The leak occurs when multiple\nthreads attempt to modify the mac_filter_hash simultaneously, leading to\ninconsistent state and potential memory leaks.\n\nTo fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing\nvf-\u003edefault_lan_addr.addr with spin_lock/unlock_bh(\u0026vsi-\u003emac_filter_hash_lock),\nensuring atomic operations and preventing concurrent access.\n\nAdditionally, we add lockdep_assert_held(\u0026vsi-\u003emac_filter_hash_lock) in\ni40e_add_mac_filter() to help catch similar issues in the future.\n\nReproduction steps:\n1. Spawn VFs and configure port vlan on them.\n2. Trigger concurrent macvlan operations (e.g., adding and deleting\n\tportvlan and/or mac filters).\n3. Observe the potential memory leak and inconsistent state in the\n\tmac_filter_hash.\n\nThis synchronization ensures the integrity of the mac_filter_hash and prevents\nthe described leak.\n\n * CVE-2024-50044: In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change\n\nrfcomm_sk_state_change attempts to use sock_lock so it must never be\ncalled with it locked but rfcomm_sock_ioctl always attempt to lock it\ncausing the following trace:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted\n------------------------------------------------------\nsyz-executor386/5093 is trying to acquire lock:\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73\n\nbut task is already holding lock:\nffff88807badfd28 (\u0026d-\u003elock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491\n\n * CVE-2024-50045: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: fix panic with metadata_dst skb\n\nFix a kernel panic in the br_netfilter module when sending untagged\ntraffic via a VxLAN device.\nThis happens during the check for fragmentation in br_nf_dev_queue_xmit.\n\nIt is dependent on:\n1) the br_netfilter module being loaded;\n2) net.bridge.bridge-nf-call-iptables set to 1;\n3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;\n4) untagged frames with size higher than the VxLAN MTU forwarded/flooded\n\nWhen forwarding the untagged packet to the VxLAN bridge port, before\nthe netfilter hooks are called, br_handle_egress_vlan_tunnel is called and\nchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata type\nof dst, i.e., skb_valid_dst(skb) is false, and metadata-\u003edst.dev is NULL.\n\nThen in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check\nfor frames that needs to be fragmented: frames with higher MTU than the\nVxLAN device end up calling br_nf_ip_fragment, which in turns call\nip_skb_dst_mtu.\n\nThe ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst\nwith valid dst-\u003edev, thus the crash.\n\nThis case was never supported in the first place, so drop the packet\ninstead.\n\nPING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.\n[ 176.291791] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000110\n[ 176.292101] Mem abort info:\n[ 176.292184] ESR = 0x0000000096000004\n[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 176.292530] SET = 0, FnV = 0\n[ 176.292709] EA = 0, S1PTW = 0\n[ 176.292862] FSC = 0x04: level 0 translation fault\n[ 176.293013] Data abort info:\n[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000\n[ 176.294166] [0000000000000110] pgd=0000000000000000,\np4d=0000000000000000\n[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth\nbr_netfilter bridge stp llc ipv6 crct10dif_ce\n[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted\n6.8.0-rc3-g5b3fbd61b9d1 #2\n[ 176.296314] Hardware name: linux,dummy-virt (DT)\n[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS\nBTYPE=--)\n[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]\n[ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]\n[ 176.297636] sp : ffff800080003630\n[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:\nffff6828c49ad9f8\n[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:\n00000000000003e8\n[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:\nffff6828c3b16d28\n[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:\n0000000000000014\n[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:\n0000000095744632\n[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:\nffffb7e137926a70\n[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :\n0000000000000000\n[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :\nf20e0100bebafeca\n[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :\n0000000000000000\n[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :\nffff6828c7f918f0\n[ 176.300889] Call trace:\n[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]\n[ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]\n[ 176.301703] nf_hook_slow+0x48/0x124\n[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge]\n[ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter]\n[ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter]\n[ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]\n[ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter]\n[ 176.303359] nf_hook_slow+0x48/0x124\n[ 176.303\n---truncated---\n\n * CVE-2024-50046: In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()\n\nOn the node of an NFS client, some files saved in the mountpoint of the\nNFS server were copied to another location of the same NFS server.\nAccidentally, the nfs42_complete_copies() got a NULL-pointer dereference\ncrash with the following syslog:\n\n[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116\n[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116\n[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n[232066.588586] Mem abort info:\n[232066.588701] ESR = 0x0000000096000007\n[232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits\n[232066.589084] SET = 0, FnV = 0\n[232066.589216] EA = 0, S1PTW = 0\n[232066.589340] FSC = 0x07: level 3 translation fault\n[232066.589559] Data abort info:\n[232066.589683] ISV = 0, ISS = 0x00000007\n[232066.589842] CM = 0, WnR = 0\n[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400\n[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000\n[232066.590757] Internal error: Oops: 96000007 [#1] SMP\n[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2\n[232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs\n[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1\n[232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06\n[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]\n[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]\n[232066.598595] sp : ffff8000f568fc70\n[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000\n[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001\n[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050\n[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000\n[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000\n[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6\n[232066.600498] x11: 00000000000000\n---truncated---\n\n * CVE-2024-50048: In the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Fix a NULL pointer dereference issue in fbcon_putcs\n\nsyzbot has found a NULL pointer dereference bug in fbcon.\nHere is the simplified C reproducer:\n\nstruct param {\n\tuint8_t type;\n\tstruct tiocl_selection ts;\n};\n\nint main()\n{\n\tstruct fb_con2fbmap con2fb;\n\tstruct param param;\n\n\tint fd = open(\"/dev/fb1\", 0, 0);\n\n\tcon2fb.console = 0x19;\n\tcon2fb.framebuffer = 0;\n\tioctl(fd, FBIOPUT_CON2FBMAP, \u0026con2fb);\n\n\tparam.type = 2;\n\tparam.ts.xs = 0; param.ts.ys = 0;\n\tparam.ts.xe = 0; param.ts.ye = 0;\n\tparam.ts.sel_mode = 0;\n\n\tint fd1 = open(\"/dev/tty1\", O_RDWR, 0);\n\tioctl(fd1, TIOCLINUX, \u0026param);\n\n\tcon2fb.console = 1;\n\tcon2fb.framebuffer = 0;\n\tioctl(fd, FBIOPUT_CON2FBMAP, \u0026con2fb);\n\n\treturn 0;\n}\n\nAfter calling ioctl(fd1, TIOCLINUX, \u0026param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, \u0026con2fb)\ncauses the kernel to follow a different execution path:\n\n set_con2fb_map\n -\u003e con2fb_init_display\n -\u003e fbcon_set_disp\n -\u003e redraw_screen\n -\u003e hide_cursor\n -\u003e clear_selection\n -\u003e highlight\n -\u003e invert_screen\n -\u003e do_update_region\n -\u003e fbcon_putcs\n -\u003e ops-\u003eputcs\n\nSince ops-\u003eputcs is a NULL pointer, this leads to a kernel panic.\nTo prevent this, we need to call set_blitting_type() within set_con2fb_map()\nto properly initialize ops-\u003eputcs.\n\n * CVE-2024-50049: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check null pointer before dereferencing se\n\n[WHAT \u0026 HOW]\nse is null checked previously in the same function, indicating\nit might be null; therefore, it must be checked when used again.\n\nThis fixes 1 FORWARD_NULL issue reported by Coverity.\n\n * CVE-2024-50059: In the Linux kernel, the following vulnerability has been resolved:\n\nntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition\n\nIn the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev\nfunction, then \u0026sndev-\u003echeck_link_status_work is bound with\ncheck_link_status_work. switchtec_ntb_link_notification may be called\nto start the work.\n\nIf we remove the module which will call switchtec_ntb_remove to make\ncleanup, it will free sndev through kfree(sndev), while the work\nmentioned above will be used. The sequence of operations that may lead\nto a UAF bug is as follows:\n\nCPU0 CPU1\n\n | check_link_status_work\nswitchtec_ntb_remove |\nkfree(sndev); |\n | if (sndev-\u003elink_force_down)\n | // use sndev\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in switchtec_ntb_remove.\n\n * CVE-2024-50062: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs-srv: Avoid null pointer deref during path establishment\n\nFor RTRS path establishment, RTRS client initiates and completes con_num\nof connections. After establishing all its connections, the information\nis exchanged between the client and server through the info_req message.\nDuring this exchange, it is essential that all connections have been\nestablished, and the state of the RTRS srv path is CONNECTED.\n\nSo add these sanity checks, to make sure we detect and abort process in\nerror scenarios to avoid null pointer deref.\n\n * #51727: Добавьте пожалуйста сборку sign-file",
|
|
"Advisory": {
|
|
"From": "errata.altlinux.org",
|
|
"Severity": "Critical",
|
|
"Rights": "Copyright 2024 BaseALT Ltd.",
|
|
"Issued": {
|
|
"Date": "2024-10-25"
|
|
},
|
|
"Updated": {
|
|
"Date": "2024-10-25"
|
|
},
|
|
"BDUs": null,
|
|
"CVEs": [
|
|
{
|
|
"ID": "CVE-2023-52917",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47678",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
|
|
"CWE": "CWE-203",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47678",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47679",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-362",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47682",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-193",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47682",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47683",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47683",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47684",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47685",
|
|
"CVSS3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685",
|
|
"Impact": "Critical",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47686",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-193",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47686",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47690",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47690",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47692",
|
|
"CVSS3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47693",
|
|
"CVSS3": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-459",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47695",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47696",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47697",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47698",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47699",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47699",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47701",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47705",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47705",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47706",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47706",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47707",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47707",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47709",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47710",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47712",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47712",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47713",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47713",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47718",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47718",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47720",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47723",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47727",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-754",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47727",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47728",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-459",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47728",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47730",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47730",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47731",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-459",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47731",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47734",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47734",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47735",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47737",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47738",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47738",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47739",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-190",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47739",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47742",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-22",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47743",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47743",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47747",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47748",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47748",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47749",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47750",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47750",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47751",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-120",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47751",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47756",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47756",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-47757",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49850",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49850",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49851",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-459",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49851",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49852",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49852",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49853",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-415",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49853",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49854",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49854",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49855",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49856",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-835",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49856",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49858",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49858",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49859",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-362",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49860",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-843",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49863",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49863",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49871",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49871",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49875",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
|
|
"CWE": "CWE-354",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49877",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49879",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49879",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49896",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49896",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49905",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49905",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49907",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49907",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49912",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49912",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-49913",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-49913",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50033",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50035",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50041",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50041",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50044",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50044",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50045",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50046",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50048",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50048",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50049",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50059",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50059",
|
|
"Impact": "High",
|
|
"Public": "20241021"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-50062",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062",
|
|
"Impact": "Low",
|
|
"Public": "20241021"
|
|
}
|
|
],
|
|
"Bugzilla": [
|
|
{
|
|
"ID": "51727",
|
|
"Href": "https://bugzilla.altlinux.org/51727",
|
|
"Data": "Добавьте пожалуйста сборку sign-file"
|
|
}
|
|
],
|
|
"AffectedCPEs": {
|
|
"CPEs": [
|
|
"cpe:/o:alt:kworkstation:10",
|
|
"cpe:/o:alt:workstation:10",
|
|
"cpe:/o:alt:server:10",
|
|
"cpe:/o:alt:server-v:10",
|
|
"cpe:/o:alt:education:10",
|
|
"cpe:/o:alt:slinux:10",
|
|
"cpe:/o:alt:starterkit:p10",
|
|
"cpe:/o:alt:kworkstation:10.1",
|
|
"cpe:/o:alt:workstation:10.1",
|
|
"cpe:/o:alt:server:10.1",
|
|
"cpe:/o:alt:server-v:10.1",
|
|
"cpe:/o:alt:education:10.1",
|
|
"cpe:/o:alt:slinux:10.1",
|
|
"cpe:/o:alt:starterkit:10.1",
|
|
"cpe:/o:alt:kworkstation:10.2",
|
|
"cpe:/o:alt:workstation:10.2",
|
|
"cpe:/o:alt:server:10.2",
|
|
"cpe:/o:alt:server-v:10.2",
|
|
"cpe:/o:alt:education:10.2",
|
|
"cpe:/o:alt:slinux:10.2",
|
|
"cpe:/o:alt:starterkit:10.2"
|
|
]
|
|
}
|
|
}
|
|
},
|
|
"Criteria": {
|
|
"Operator": "AND",
|
|
"Criterions": [
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:2001",
|
|
"Comment": "ALT Linux must be installed"
|
|
}
|
|
],
|
|
"Criterias": [
|
|
{
|
|
"Operator": "OR",
|
|
"Criterions": [
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268001",
|
|
"Comment": "kernel-doc-un is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268002",
|
|
"Comment": "kernel-headers-modules-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268003",
|
|
"Comment": "kernel-headers-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268004",
|
|
"Comment": "kernel-image-domU-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268005",
|
|
"Comment": "kernel-image-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268006",
|
|
"Comment": "kernel-image-un-def-checkinstall is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268007",
|
|
"Comment": "kernel-modules-drm-ancient-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268008",
|
|
"Comment": "kernel-modules-drm-nouveau-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268009",
|
|
"Comment": "kernel-modules-drm-un-def is earlier than 1:6.1.113-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202414268010",
|
|
"Comment": "kernel-modules-staging-un-def is earlier than 1:6.1.113-alt1"
|
|
}
|
|
]
|
|
}
|
|
]
|
|
}
|
|
}
|
|
]
|
|
} |