Skip to content

media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format #108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Feb 7, 2025
Merged

media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format #108

merged 1 commit into from
Feb 7, 2025

Conversation

bmastbergen
Copy link
Collaborator

jira VULN-9661
cve CVE-2024-53104

commit-author Benoit Sevens <[email protected]>
commit ecf2b43018da9579842c774b7f35dbe11b5c38dd

This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.

Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver")
	Signed-off-by: Benoit Sevens <[email protected]>
	Cc: [email protected]
	Acked-by: Greg Kroah-Hartman <[email protected]>
	Reviewed-by: Laurent Pinchart <[email protected]>
	Signed-off-by: Hans Verkuil <[email protected]>
(cherry picked from commit ecf2b43018da9579842c774b7f35dbe11b5c38dd)
	Signed-off-by: Brett Mastbergen <[email protected]>

Same as #107

build.log

The very limited number of selftests were run before and after (with little success in either case):
selftests-before.log
selftests-after.log

brett@lycia ~/ciq/vuln-9661 % grep ^ok selftests-before.log | wc -l
2
brett@lycia ~/ciq/vuln-9661 % grep ^ok selftests-after.log | wc -l
2
brett@lycia ~/ciq/vuln-9661 %

@bmastbergen
media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_…
04348ea 
…parse_format

jira VULN-9661
cve CVE-2024-53104
commit-author Benoit Sevens <[email protected]>
commit ecf2b43

This can lead to out of bounds writes since frames of this type were not
taken into account when calculating the size of the frames buffer in
uvc_parse_streaming.

Fixes: c0efd23 ("V4L/DVB (8145a): USB Video Class driver")
	Signed-off-by: Benoit Sevens <[email protected]>
	Cc: [email protected]
	Acked-by: Greg Kroah-Hartman <[email protected]>
	Reviewed-by: Laurent Pinchart <[email protected]>
	Signed-off-by: Hans Verkuil <[email protected]>
(cherry picked from commit ecf2b43)
	Signed-off-by: Brett Mastbergen <[email protected]>
@jason-rodri
Copy link

Will you need this commit as well? 2b64cea

PlaidCat
PlaidCat approved these changes Feb 7, 2025
View reviewed changes
Copy link
Collaborator

@PlaidCat PlaidCat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@PlaidCat
Copy link
Collaborator

PlaidCat commented Feb 7, 2025

Note: we still don't have builder checks for CentOS7.9

gvrose8192
gvrose8192 approved these changes Feb 7, 2025
View reviewed changes
Copy link

@gvrose8192 gvrose8192 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - Thanks!

@bmastbergen bmastbergen merged commit 96268d4 into ciqcbr7_9 Feb 7, 2025
@bmastbergen bmastbergen deleted the bmastbergen_ciqcbr7_9/VULN-9661 branch February 7, 2025 19:38
@jason-rodri
Copy link

Double checked on ftype due to it not being initialized. ftype is assigned before check in while look

@bmastbergen bmastbergen mentioned this pull request Feb 11, 2025
Merged
github-actions bot pushed a commit that referenced this pull request Jul 24, 2025
@boryas @gregkh
btrfs: fix block group refcount race in btrfs_create_pending_block_gr…
ee56da9 
…oups()

commit 2d8e516 upstream.

Block group creation is done in two phases, which results in a slightly
unintuitive property: a block group can be allocated/deallocated from
after btrfs_make_block_group() adds it to the space_info with
btrfs_add_bg_to_space_info(), but before creation is completely completed
in btrfs_create_pending_block_groups(). As a result, it is possible for a
block group to go unused and have 'btrfs_mark_bg_unused' called on it
concurrently with 'btrfs_create_pending_block_groups'. This causes a
number of issues, which were fixed with the block group flag
'BLOCK_GROUP_FLAG_NEW'.

However, this fix is not quite complete. Since it does not use the
unused_bg_lock, it is possible for the following race to occur:

btrfs_create_pending_block_groups            btrfs_mark_bg_unused
                                           if list_empty // false
        list_del_init
        clear_bit
                                           else if (test_bit) // true
                                                list_move_tail

And we get into the exact same broken ref count and invalid new_bgs
state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to
prevent.

The broken refcount aspect will result in a warning like:

  [1272.943527] refcount_t: underflow; use-after-free.
  [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
  [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]
  [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G        W          6.14.0-rc5+ #108
  [1272.946368] Tainted: [W]=WARN
  [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
  [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]
  [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110
  [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282
  [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000
  [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff
  [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268
  [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0
  [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0
  [1272.952850] FS:  0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000
  [1272.953458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0
  [1272.954474] Call Trace:
  [1272.954655]  <TASK>
  [1272.954812]  ? refcount_warn_saturate+0xba/0x110
  [1272.955173]  ? __warn.cold+0x93/0xd7
  [1272.955487]  ? refcount_warn_saturate+0xba/0x110
  [1272.955816]  ? report_bug+0xe7/0x120
  [1272.956103]  ? handle_bug+0x53/0x90
  [1272.956424]  ? exc_invalid_op+0x13/0x60
  [1272.956700]  ? asm_exc_invalid_op+0x16/0x20
  [1272.957011]  ? refcount_warn_saturate+0xba/0x110
  [1272.957399]  btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs]
  [1272.957853]  btrfs_put_block_group.cold+0x5d/0x8e [btrfs]
  [1272.958289]  btrfs_discard_workfn+0x194/0x380 [btrfs]
  [1272.958729]  process_one_work+0x130/0x290
  [1272.959026]  worker_thread+0x2ea/0x420
  [1272.959335]  ? __pfx_worker_thread+0x10/0x10
  [1272.959644]  kthread+0xd7/0x1c0
  [1272.959872]  ? __pfx_kthread+0x10/0x10
  [1272.960172]  ret_from_fork+0x30/0x50
  [1272.960474]  ? __pfx_kthread+0x10/0x10
  [1272.960745]  ret_from_fork_asm+0x1a/0x30
  [1272.961035]  </TASK>
  [1272.961238] ---[ end trace 0000000000000000 ]---

Though we have seen them in the async discard workfn as well. It is
most likely to happen after a relocation finishes which cancels discard,
tears down the block group, etc.

Fix this fully by taking the lock around the list_del_init + clear_bit
so that the two are done atomically.

Fixes: 0657b20 ("btrfs: fix use-after-free of new block group that became unused")
Reviewed-by: Qu Wenruo <[email protected]>
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Boris Burkov <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Alva Lan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gvrose8192 gvrose8192 gvrose8192 approved these changes

@PlaidCat PlaidCat PlaidCat approved these changes

@jason-rodri jason-rodri jason-rodri approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@bmastbergen @jason-rodri @PlaidCat @gvrose8192